[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[Inada Naoki]

Inada Naoki  added the comment:


New changeset 151b91dfd21a100ecb1eba9e293c0a8695bf3bf5 by Inada Naoki (Jeroen 
Demeyer) in branch 'master':
bpo-29548: deprecate PyEval_Call* functions (GH-14804)
https://github.com/python/cpython/commit/151b91dfd21a100ecb1eba9e293c0a8695bf3bf5


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
pull_requests: +14600
pull_request: https://github.com/python/cpython/pull/14804

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[Inada Naoki]

Inada Naoki  added the comment:


New changeset 1dbd084f1f68d7293718b663df675cfbd0c65712 by Inada Naoki (Jeroen 
Demeyer) in branch 'master':
bpo-29548: no longer use PyEval_Call* functions (GH-14683)
https://github.com/python/cpython/commit/1dbd084f1f68d7293718b663df675cfbd0c65712


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[Inada Naoki]

Inada Naoki  added the comment:

FYI, PyEval_CallFunction and PyEval_CallMethod doesn't respect Py_SSIZE_T_CLEAN.
So runtime warning is raised when they are used with "#" format.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

I understand the arguments for not removing these functions. However, I still 
think that we should deprecate them but without planning in advance when they 
should be removed. Victor said that we should document these functions as 
"please don't use them", and that is exactly what a deprecation message 
accomplishes.

Most other projects that I know have only a minimum deprecation period (i.e. 
feature X can only be removed if it was deprecated for Y time). I don't 
understand why CPython insists that the minimum of 2 releases should also be a 
maximum (i.e. feature X MUST be removed after it was deprecated for Y time). I 
don't see the problem with long-term deprecations for stuff that we don't plan 
to remove soon.

--
nosy: +jdemeyer

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
pull_requests: +14488
pull_request: https://github.com/python/cpython/pull/14683

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[INADA Naoki]

INADA Naoki added the comment:


New changeset aa289a59ff6398110e1122877c073c9354ee53db by INADA Naoki in branch 
'master':
bpo-29548: Recommend PyObject_Call APIs over PyEval_Call APIs. (GH-75)
https://github.com/python/cpython/commit/aa289a59ff6398110e1122877c073c9354ee53db


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[INADA Naoki]

Changes by INADA Naoki :


--
dependencies:  -Document PyEval_Call* functions
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[Ezio Melotti]

Changes by Ezio Melotti :


--
Removed message: http://bugs.python.org/msg288059

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[Nick Coghlan]

Nick Coghlan added the comment:


New changeset 72dccde884d89586b0cafd990675b7e21720a81f by GitHub in branch 
'ncoghlan-devguide-link':
bpo-29548: Fix some inefficient call API usage (GH-97)
https://github.com/python/cpython/commit/72dccde884d89586b0cafd990675b7e21720a81f


--
nosy: +ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[INADA Naoki]

INADA Naoki added the comment:


New changeset 72dccde884d89586b0cafd990675b7e21720a81f by GitHub in branch 
'master':
bpo-29548: Fix some inefficient call API usage (GH-97)
https://github.com/python/cpython/commit/72dccde884d89586b0cafd990675b7e21720a81f


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[STINNER Victor]

STINNER Victor added the comment:

> # builtin min and max doesn't support FASTCALL
> (...): 1.16x slower (+16%)

Hum, the slowdown is not negligible, even if functools.reduce() is rarely used.

Do you think that it would be insane to have two code paths instead?

* New FASTCALL path if func suports FASTCALL calling _PyObject_FastCall()
* Current code path using cached args tuple otherwise

For example, you can use args==NULL marker for the FASTCALL path. Maybe we need 
a _PyObject_SupportFastCall() function which would return 1 for Python 
functions and C functions, except of C functions with METH_VARARGS flag set.

My expectation is a speedup for functions supporting FASTCALL, but *no 
slowdown* for functions not supporting FASTCALL.

--

property_descr_get() also caches args tuple. I started my work on FASTCALL 
because this optimization caused bugs (but also because I wanted to make Python 
faster, but that's a different topic ;-)).

In the past, the _pickle module also used cached args tuple, but the cache was 
removed because it was vulnerable to race conditions.

For this issue, I suggest to leave functools.reduce() unchanged, but open a new 
issue to discuss what to do with code still using a cached args tuple.

My long term goal with FASTCALL was to remove completely cached tuple used to 
call functions. I wrote tp_fastcall for that, but tp_fastcall (issue #29259) 
was rejected. The rejected tp_fastcall blocked my long term plan, we have to 
find a different approach.

Maybe we should add support for FASTCALL for a little bit more functions, and 
later simply remove the optimization (hack, cached tuple)?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[INADA Naoki]

Changes by INADA Naoki :


--
pull_requests: +82

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[STINNER Victor]

STINNER Victor added the comment:

"I think first at all PyEval_Call* functions should be documented
(issue11165). The documentation should recommend to use corresponding
PyObject_Call* functions (...)"

I *now* agree :-)

--
title: Recommend PyObject_Call* APIs  over PyEval_Call*() APIs -> Recommend 
PyObject_Call* APIs over PyEval_Call*() APIs

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think first at all PyEval_Call* functions should be documented (issue11165). 
The documentation should recommend to use corresponding PyObject_Call* 
functions and explicitly describe the difference between PyEval_Call* and 
PyObject_Call* APIs.

Few releases after deprecating PyEval_Call APIs in documentation we can add the 
Py_DEPRECATED attribute for emitting compiler warnings. Few releases after 
deprecating in code we can remove PyEval_Call* declarations from headers, but 
keep exporting them in binary library. In Python 4 (or other major release that 
will break binary compatibility) they can be removed at all.

--
dependencies: +Document PyEval_Call* functions

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

[INADA Naoki]

INADA Naoki added the comment:

I've stopped to deprecating.  changed issue title.

--
title: deprecate PyEval_Call*() functions. -> Recommend PyObject_Call* APIs  
over PyEval_Call*() APIs

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com