Message 287752 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	methane
Recipients	lemburg, mark.dickinson, methane, serhiy.storchaka, vstinner
Date	2017-02-14.09:49:03
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<[email protected]>
In-reply-to

Content
> The argument tuple can be NULL for PyEval_CallObject() (it then gets replaced with an empty tuple), but will raise a segfault for PyObject_Call(). PyObject_CallObject() accepts NULL as args. Macro vs function is only difference of them. On the other hand, PyObject_CallObjectWithKeyword() doesn't have identical function. So I agree your suggestion to add NULL support to PyObject_Call(). We have more fast _PyObject_FastCall* APIs for performance critical code. Additional cost to check NULL in PyObject_Call() would be negligible. Any opinion from others?

> The argument tuple can be NULL for PyEval_CallObject() (it then gets replaced with an empty tuple), but will raise a segfault for PyObject_Call().

PyObject_CallObject() accepts NULL as args. Macro vs function is only difference of them.

On the other hand, PyObject_CallObjectWithKeyword() doesn't have identical function.
So I agree your suggestion to add NULL support to PyObject_Call().

We have more fast _PyObject_FastCall* APIs for performance critical code.
Additional cost to check NULL in PyObject_Call() would be negligible.

Any opinion from others?

History
Date	User	Action	Args
2017-02-14 09:49:03	methane	set	recipients: + methane, lemburg, mark.dickinson, vstinner, serhiy.storchaka
2017-02-14 09:49:03	methane	set	messageid: <[email protected]>
2017-02-14 09:49:03	methane	link	issue29548 messages
2017-02-14 09:49:03	methane	create