[issue29548] deprecate PyEval_Call*() functions.

Raymond Hettinger added the comment: In general, we should have a strong aversion to deprecation except in cases where something is actually broken. API changes make it more difficult for people to migrate to Python 3 or to upgrade between minor releases. The longer an API has existed,

[issue29548] deprecate PyEval_Call*() functions.

INADA Naoki added the comment: I stopped deprecating PyEval_Call APIs, and removing it's usage in PR 75. Summary of current pull requests: PR 87 contains fix regression of PyEval_CallObjectWithKeywords for Python 3.6. PR 75 is for master branch. It contains fix same to PR 87. Additionally,

[issue29548] deprecate PyEval_Call*() functions.

STINNER Victor added the comment: > So they are part of stable ABI. We can't remove them until Python 4. Please just stop right now using "Python 4" as the starting point to break -again- the Python world. If you plan to remove the function, plan it right now with versions like "in 2 cycles".

[issue29548] deprecate PyEval_Call*() functions.

INADA Naoki added the comment: > I would suggest to deprecate PyEval_Call*() functions first only in the > documentation. In 3.8 or 3.9 add the Py_DEPRECATED attribute. doesn't excluded by PEP 384. And these 3 functions and 1 macro is outside of "#ifndef Py_LIMITED_API" check. So they are

[issue29548] deprecate PyEval_Call*() functions.

Serhiy Storchaka added the comment: > Any idea of the popularity of the undocumented PyEval_xxx() functions? You can just search code at GitHub. I would suggest to deprecate PyEval_Call*() functions first only in the documentation. In 3.8 or 3.9 add the Py_DEPRECATED attribute. --

[issue29548] deprecate PyEval_Call*() functions.

Serhiy Storchaka added the comment: PyEval_CallObject() was added at Jan 12 1995 (05360cd616ae). PyObject_CallObject(), PyObject_CallFunction() and PyObject_CallMethod() were added with Include/abstract.h at Jul 18 1995 (d5398acafa2c) and implemented in terms of PyEval_CallObject().

[issue29548] deprecate PyEval_Call*() functions.

Marc-Andre Lemburg added the comment: On 14.02.2017 11:16, STINNER Victor wrote: > >> Please note that the two sets of APIs are not identical, e.g. you cannot >> simply replace PyEval_CallObject() with PyObject_Call(), since the former >> applies a few extra checks and defaults, which the

[issue29548] deprecate PyEval_Call*() functions.

INADA Naoki added the comment: > I'm more in favor of modifying PyEval_xxx() to call PyObject_xxx() and > deprecate them. That's PR 75 :) -- ___ Python tracker

[issue29548] deprecate PyEval_Call*() functions.

STINNER Victor added the comment: > Please note that the two sets of APIs are not identical, e.g. you cannot > simply replace PyEval_CallObject() with PyObject_Call(), since the former > applies a few extra checks and defaults, which the latter doesn't. IMHO these checks are too expensive at

[issue29548] deprecate PyEval_Call*() functions.

STINNER Victor added the comment: "you now add the extra support for args being NULL to PyObject_Call()" I dislike this idea. I don't want to change the API of this function. If it is likely that NULL is the result of a previous error: args = Py_BuildValue(...); res = PyObject_Call(func,

[issue29548] deprecate PyEval_Call*() functions.

Marc-Andre Lemburg added the comment: Looking through Python's history, it's interesting that PyObject_Call() did apply the args == NULL checks up until Python 2.1. In Python 2.2 this was replaced by a direct call to tp_call, without the checks. However, the tp_call slots don't do this check

[issue29548] deprecate PyEval_Call*() functions.

INADA Naoki added the comment: > 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,

[issue29548] deprecate PyEval_Call*() functions.

Marc-Andre Lemburg added the comment: Thanks, but you missed the main difference: 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(). Now, apart from looking at the use cases in the core, you also

[issue29548] deprecate PyEval_Call*() functions.

Serhiy Storchaka added the comment: See also issue485165, issue8276 and issue11173. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue29548] deprecate PyEval_Call*() functions.

Mark Dickinson added the comment: See also #11165 -- nosy: +mark.dickinson ___ Python tracker ___ ___

[issue29548] deprecate PyEval_Call*() functions.

INADA Naoki added the comment: PR 87 fixes the regression in 3.6 branch -- pull_requests: +55 ___ Python tracker ___

[issue29548] deprecate PyEval_Call*() functions.

Changes by INADA Naoki : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list

[issue29548] deprecate PyEval_Call*() functions.

INADA Naoki added the comment: Thanks, Lemburg to pointing it out. Here is detail of the difference. ## PyEval_CallFunction(), PyEval_CallMethod() They are very similar to PyObject_CallFunction() and PyObject_CallMethod(). difference are: * PyEval_Call...() doesn't respect Py_SSIZE_T_CLEAN

[issue29548] deprecate PyEval_Call*() functions.

Marc-Andre Lemburg added the comment: Please note that the two sets of APIs are not identical, e.g. you cannot simply replace PyEval_CallObject() with PyObject_Call(), since the former applies a few extra checks and defaults, which the latter doesn't. -- nosy: +lemburg

[issue29548] deprecate PyEval_Call*() functions.

Changes by INADA Naoki : -- pull_requests: +54 ___ Python tracker ___ ___

[issue29548] deprecate PyEval_Call*() functions.

New submission from INADA Naoki: As reading call.c, PyEval_Call* APIs are mostly duplicate of PyObject_Call* APIs. While they are not documented, they seems part of limited APIs. So we can't remove them easily. Let's deprecate them for now. -- components: Interpreter Core messages: