[docs] [issue28977] Document PyObject_CallFunction() special case more explicitly
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>
More information about the docs