[Python-Dev] PEP 575: Unifying function/method classes

[Jeroen Demeyer]

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.