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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com