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

[Robert Bradshaw]

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.Demeyer at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/robertwb%
> 40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180502/287715bc/attachment-0001.html>