diff options
author | Guido van Rossum <guido@python.org> | 2001-09-14 16:47:50 (GMT) |
---|---|---|
committer | Guido van Rossum <guido@python.org> | 2001-09-14 16:47:50 (GMT) |
commit | 5560b7492c8dbe17a29362a66102662e5e22a9d2 (patch) | |
tree | cfa8c5ccf8e7fc730534321a5925186a4d809566 /Mac | |
parent | d8185ca43eedc9262ac7744f4c48dc2313c5d1fb (diff) | |
download | cpython-5560b7492c8dbe17a29362a66102662e5e22a9d2.zip cpython-5560b7492c8dbe17a29362a66102662e5e22a9d2.tar.gz cpython-5560b7492c8dbe17a29362a66102662e5e22a9d2.tar.bz2 |
PyObject_CallObject(): this may as well call PyEval_CallObject()
directly, as the only thing done here (replace NULL args with an empty
tuple) is also done there.
XXX Maybe we should take one step further and equate the two at the
macro level? That's harder though because PyEval_Call* is declared in
a header that's not included standard. But it is silly that
PyObject_CallObject calls PyEval_CallObject which calls back to
PyObject_Call. Maybe PyEval_CallObject should be moved into this file
instead? All I know is that there are too many call APIs! The
differences between PyObject_Call and PyEval_CallObjectWithKeywords is
that the latter allows args to be NULL, and does explicit type checks
for args and kwds.
Diffstat (limited to 'Mac')
0 files changed, 0 insertions, 0 deletions