[issue23990] Callable builtin doesn't respect descriptors
Christian Heimes
report at bugs.python.org
Sat Apr 18 20:00:34 CEST 2015
Christian Heimes added the comment:
On 2015-04-18 19:43, Ionel Cristian Mărieș wrote:
>
> Ionel Cristian Mărieș added the comment:
>
> On Sat, Apr 18, 2015 at 8:35 PM, Christian Heimes <report at bugs.python.org>
> wrote:
>
>> You also haven't shown that this behavior violates the documentation and
>> language spec.
>
> How can I show it violates the "spec" when there's not such thing? :-)
> AFAIK, `callable` is not specified in any PEP. Please give some references
> when you make such statements.
The language specs is made up from two things:
1) the CPython reference implemention
2) the documentation of the CPython reference implementation
3) accepted and implemented PEPs
If 3) doesn't exist and 2) doesn't contain any point that contradicts
1), then 1) and 2) agree on an implementation and therefore it is
informally specified. The fact that PyPy and Jython show the same
behavior, adds additional weight to 1), too.
callable() has been implemented like that since the introduction of new
style classes, too.
$ hg checkout v2.2
$ grep -A20 ^PyCallable_Check Objects/object.c
PyCallable_Check(PyObject *x)
{
if (x == NULL)
return 0;
if (PyInstance_Check(x)) {
PyObject *call = PyObject_GetAttrString(x, "__call__");
if (call == NULL) {
PyErr_Clear();
return 0;
}
/* Could test recursively but don't, for fear of endless
recursion if some joker sets self.__call__ = self */
Py_DECREF(call);
return 1;
}
else {
return x->ob_type->tp_call != NULL;
}
}
You really have to make a *very* good case with a PEP in order to get
everybody to switch to a different behavior!
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________
More information about the Python-bugs-list
mailing list