Victor Stinner [Fri, 9 Dec 2016 15:22:32 +0000 (16:22 +0100)]
Use PyObject_CallFunctionObjArgs()
Issue #28915: Replace PyObject_CallFunction() with
PyObject_CallFunctionObjArgs() when the format string was only made of "O"
formats, PyObject* arguments.
PyObject_CallFunctionObjArgs() avoids the creation of a temporary tuple and
doesn't have to parse a format string.
Victor Stinner [Fri, 9 Dec 2016 15:09:30 +0000 (16:09 +0100)]
Use _PyObject_CallMethodIdObjArgs()
Issue #28915: Replace _PyObject_CallMethodId() with
_PyObject_CallMethodIdObjArgs() in various modules when the format string was
only made of "O" formats, PyObject* arguments.
_PyObject_CallMethodIdObjArgs() avoids the creation of a temporary tuple and
doesn't have to parse a format string.
Victor Stinner [Fri, 9 Dec 2016 14:39:28 +0000 (15:39 +0100)]
Use _PyObject_CallMethodIdObjArgs() in _io
Issue #28915: Replace _PyObject_CallMethodId() with
_PyObject_CallMethodIdObjArgs() when the format string was only made of "O"
formats, PyObject* arguments.
_PyObject_CallMethodIdObjArgs() avoids the creation of a temporary tuple and
doesn't have to parse a format string.
Victor Stinner [Fri, 9 Dec 2016 14:24:31 +0000 (15:24 +0100)]
Use _PyObject_CallMethodIdObjArgs() in _datetime
Issue #28915: Replace _PyObject_CallMethodId() with
_PyObject_CallMethodIdObjArgs() when the format string was only made of "O"
formats, PyObject* arguments.
_PyObject_CallMethodIdObjArgs() avoids the creation of a temporary tuple and
doesn't have to parse a format string.
Victor Stinner [Fri, 9 Dec 2016 14:26:00 +0000 (15:26 +0100)]
Use _PyObject_CallMethodIdObjArgs() in _elementtree
Issue #28915: Replace _PyObject_CallMethodId() with
_PyObject_CallMethodIdObjArgs() when the format string was only made of "O"
formats, PyObject* arguments.
_PyObject_CallMethodIdObjArgs() avoids the creation of a temporary tuple and
doesn't have to parse a format string.
Victor Stinner [Fri, 9 Dec 2016 14:18:31 +0000 (15:18 +0100)]
Use _PyObject_CallMethodIdObjArgs() in _ctypes
Issue #28915: Replace _PyObject_CallMethodId() with
_PyObject_CallMethodIdObjArgs() in unpickle(). _PyObject_CallMethodIdObjArgs()
avoids the creation of a temporary tuple and doesn't have to parse a format
string.
Replace _PyObject_CallMethodId() with _PyObject_GetAttrId()+PyObject_Call() for
the second call since it requires to "unpack" a tuple.
Add also a check in the type of the second parameter (state): it must be a
tuple.
Victor Stinner [Fri, 9 Dec 2016 13:24:02 +0000 (14:24 +0100)]
Use _PyObject_CallMethodIdObjArgs() in _asyncio
Issue #28915: Replace _PyObject_CallMethodId() with
_PyObject_CallMethodIdObjArgs() when the format string was only made of "O"
formats, PyObject* arguments.
_PyObject_CallMethodIdObjArgs() avoids the creation of a temporary tuple and
doesn't have to parse a format string.
Xavier de Gaye [Fri, 9 Dec 2016 08:33:09 +0000 (09:33 +0100)]
Issue #26937: The chown() method of the tarfile.TarFile class does not fail now
when the grp module cannot be imported, as for example on Android platforms.
Victor Stinner [Thu, 8 Dec 2016 23:38:53 +0000 (00:38 +0100)]
time_strptime() uses PyObject_Call()
Issue #28915: Use PyObject_Call() to pass a tuple of positional arguments,
instead of relying on _PyObject_CallMethodId() weird behaviour to unpack the
tuple.
Victor Stinner [Thu, 8 Dec 2016 23:38:16 +0000 (00:38 +0100)]
build_struct_time() uses Py_BuildValue()
Issue #28915: Avoid calling _PyObject_CallMethodId() with "(...)" format to
avoid the creation of a temporary tuple: use Py_BuildValue() with
_PyObject_CallMethodIdObjArgs().
Victor Stinner [Thu, 8 Dec 2016 23:36:19 +0000 (00:36 +0100)]
Use _PyObject_CallMethodIdObjArgs()
Issue #28915: Replace _PyObject_CallMethodId() with
_PyObject_CallMethodIdObjArgs() when the format string only use the format 'O'
for objects, like "(O)".
_PyObject_CallMethodIdObjArgs() avoids the code to parse a format string and
avoids the creation of a temporary tuple.
Victor Stinner [Thu, 8 Dec 2016 23:27:22 +0000 (00:27 +0100)]
modsupport: replace int with Py_ssize_t
Issue #28915: Py_ssize_t type is better for indexes. The compiler might emit
more efficient code for i++. Py_ssize_t is the type of a PyTuple index for
example.
Issue #28847: A deprecation warning is now emitted if the index file is missed
and recreated in the 'r' and 'w' modes (will be an error in future Python
releases).
Victor Stinner [Tue, 6 Dec 2016 15:27:24 +0000 (16:27 +0100)]
Uniformize argument names of "call" functions
Issue #28838: Rename parameters of the "calls" functions of the Python C API.
* Rename 'callable_object' and 'func' to 'callable': any Python callable object
is accepted, not only Python functions
* Rename 'method' and 'nameid' to 'name' (method name)
* Rename 'o' to 'obj'
* Move, fix and update documentation of PyObject_CallXXX() functions
in abstract.h
* Update also the documentaton of the C API (update parameter names)
Victor Stinner [Mon, 5 Dec 2016 16:04:32 +0000 (17:04 +0100)]
Issue #28858: Remove _PyObject_CallArg1() macro
Replace
_PyObject_CallArg1(func, arg)
with
PyObject_CallFunctionObjArgs(func, arg, NULL)
Using the _PyObject_CallArg1() macro increases the usage of the C stack, which
was unexpected and unwanted. PyObject_CallFunctionObjArgs() doesn't have this
issue.
Nick Coghlan [Mon, 5 Dec 2016 06:47:55 +0000 (16:47 +1000)]
Issue #23722: improve __classcell__ compatibility
Handling zero-argument super() in __init_subclass__ and
__set_name__ involved moving __class__ initialisation to
type.__new__. This requires cooperation from custom
metaclasses to ensure that the new __classcell__ entry
is passed along appropriately.
The initial implementation of that change resulted in abruptly
broken zero-argument super() support in metaclasses that didn't
adhere to the new requirements (such as Django's metaclass for
Model definitions).
The updated approach adopted here instead emits a deprecation
warning for those cases, and makes them work the same way they
did in Python 3.5.
This patch also improves the related class machinery documentation
to cover these details and to include more reader-friendly
cross-references and index entries.
Issue #28858: The change b9c9691c72c5 introduced a regression. It seems like
_PyObject_CallArg1() uses more stack memory than
PyObject_CallFunctionObjArgs().