This would be really useful for Cython, as well as a nice cleanup in general (e.g. replacing 4 special cases with one check).
It seems the main concern is the user-visible change in types. If this is determined to be too backwards incompatible (I would be surprised if many projects are impacted, but also surprised if none are--more data is warranted) I think the main points of this proposal could be addressed by introducing the common superclass(es) while keeping the "leaf" types of builtin_function_or_method, etc. exactly the same similar to the two-phase proposal (though of course it'd be a nice to split this up, as well as unify normal-method and c-defined-method if that's palatable). - Robert On Mon, Apr 30, 2018 at 8:55 AM, Jeroen Demeyer <j.deme...@ugent.be> wrote: > On 2018-04-30 15:38, Mark Shannon wrote: > >> While a unified *interface* makes sense, a unified class hierarchy and >> implementation, IMO, do not. >> > > The main reason for the common base class is performance: in the bytecode > interpreter, when we call an object, CPython currently has a special case > for calling Python functions, a special case for calling methods, a special > case for calling method descriptors, a special case for calling built-in > functions. > > By introducing a common base class, we reduce the number of special cases. > Second, we allow using this fast path for custom classes. With PEP 575, it > is possible to create new classes with the same __call__ performance as the > current built-in function class. > > Bound-methods may be callables, but they are not functions, they are a >> pair of a function and a "self" object. >> > > From the Python language point of view, that may be true but that's not > how you want to implement methods. When I write a method in C, I want that > it can be called either as unbound method or as bound method: the C code > shouldn't see the difference between the calls X.foo(obj) or obj.foo(). And > you want both calls to be equally fast, so you don't want that the bound > method just wraps the unbound method. For this reason, it makes sense to > unify functions and methods. > > IMO, there are so many versions of "function" and "bound-method", that a >> unified class hierarchy and the resulting restriction to the >> implementation will make implementing a unified interface harder, not >> easier. >> > > PEP 575 does not add any restrictions: I never claimed that all callables > should inherit from base_function. Regardless, why would the common base > class add restrictions? You can still add attributes and customize whatever > you want in subclasses. > > > > Jeroen. > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/robertwb% > 40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com