summaryrefslogtreecommitdiffstats
path: root/Objects
diff options
context:
space:
mode:
authorGuido van Rossum <guido@python.org>2001-09-14 16:47:50 (GMT)
committerGuido van Rossum <guido@python.org>2001-09-14 16:47:50 (GMT)
commit5560b7492c8dbe17a29362a66102662e5e22a9d2 (patch)
treecfa8c5ccf8e7fc730534321a5925186a4d809566 /Objects
parentd8185ca43eedc9262ac7744f4c48dc2313c5d1fb (diff)
downloadcpython-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 'Objects')
-rw-r--r--Objects/abstract.c17
1 files changed, 1 insertions, 16 deletions
diff --git a/Objects/abstract.c b/Objects/abstract.c
index c44f8c2..fdf1a44 100644
--- a/Objects/abstract.c
+++ b/Objects/abstract.c
@@ -1615,22 +1615,7 @@ PyMapping_HasKey(PyObject *o, PyObject *key)
PyObject *
PyObject_CallObject(PyObject *o, PyObject *a)
{
- PyObject *r;
- PyObject *args = a;
-
- if (args == NULL) {
- args = PyTuple_New(0);
- if (args == NULL)
- return NULL;
- }
-
- r = PyEval_CallObject(o, args);
-
- if (args != a) {
- Py_DECREF(args);
- }
-
- return r;
+ return PyEval_CallObjectWithKeywords(o, a, NULL);
}
PyObject *