<div dir="ltr">This would be really useful for Cython, as well as a nice cleanup in general (e.g. replacing 4 special cases with one check).<div><br></div><div>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).</div><div><br></div><div>- Robert</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 30, 2018 at 8:55 AM, Jeroen Demeyer <span dir="ltr"><<a href="mailto:J.Demeyer@ugent.be" target="_blank">J.Demeyer@ugent.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2018-04-30 15:38, Mark Shannon wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While a unified *interface* makes sense, a unified class hierarchy and<br>
implementation, IMO, do not.<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Bound-methods may be callables, but they are not functions, they are a<br>
pair of a function and a "self" object.<br>
</blockquote>
<br></span>
>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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IMO, there are so many versions of "function" and "bound-method", that a<br>
unified class hierarchy and the resulting restriction to the<br>
implementation will make implementing a unified interface harder, not<br>
easier.<br>
</blockquote>
<br></span>
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.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
Jeroen.<br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/robertwb%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/options/python-dev/robertwb%<wbr>40gmail.com</a><br>
</div></div></blockquote></div><br></div>