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@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!