[docs] [issue28977] Document PyObject_CallFunction() special case more explicitly

Serhiy Storchaka report at bugs.python.org
Fri Dec 16 03:49:51 EST 2016


Serhiy Storchaka added the comment:

> All other format codes are illegal for single argument.

I was wrong. PyObject_CallFunction() handles correctly a single non-tuple 
argument. The problem is only with tuple result of Py_BuildValue().

> What do you mean exactly by deprecating the feature? Emit a warning if and
> only if te format string is "O" (or "S" or "N") and Py_BuildValue() returns
> a tuple?

Emit a FutureWarning if the format string contains the single format code and 
Py_BuildValue() returns a tuple. In 3.8 or 3.9 the behavior will be changed.

> I dislike this path
> because developers would try to make the warning quiet in Python 3.7, for
> example use "(O)" format string, which is less obvious and looks like a
> hack to me.

PyObject_CallFunctionObjArgs(func, arg, NULL) seems obvious and perhaps even 
more efficient in all versions.

> More and more applications use Python bleeding edge (the development branch,
> default), and more and more developers quickly test their application on
> the new Python stable release. Maybe we can "simply" fix the behaviour of
> PyObject_CallFunction() with no transition period:

Ask on Python-Dev. I afraid this is too dangerous. We should have at least one 
release with a FutureWarning.

> Most developers don't expect the feature and so write
> code which doesn't work with tuple arguments.

That is why we should add a FutureWarning. If the code doesn't fail by 
accident, but just works incorrectly, this can be unnoticed. FutureWarning 
could help to fix possible bugs in older Python versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28977>
_______________________________________


More information about the docs mailing list