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 <rep...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue23990> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com