[Python-Dev] PEP: 576 Title: Rationalize Built-in function classes

Jeroen Demeyer J.Demeyer at UGent.be
Sun May 20 15:26:00 EDT 2018

On 2018-05-19 11:15, mark wrote:
> PEP 576 aims to fulfill the same goals as PEP 575

(this is a copy of my comments on GitHub before this PEP was official)


Most importantly, changing bound methods of extension types from 
builtin_function_or_method to bound_method will yield a performance 
loss. It might be possible to mitigate this somewhat by adding specific 
optimizations for calling bound_method. However, that would add extra 
complexity and it will probably still be slower than the existing code.

And I would also like to know whether it will be possible for custom 
built-in function subclasses to implement __get__ to change a function 
into a method (like Python functions) and whether/how the LOAD_METHOD 
opcode will work in that case.


When I want "introspection support", that goes beyond the call 
signature. Also inspect.getfile should be supported. Currently, that 
simply raises an exception for built-in functions.

I think it's important to specify the semantics of inspect.isfunction. 
Given that you don't mention it, I assume that inspect.isfunction will 
continue to return True only for Python functions. But that way, these 
new function classes won't behave like Python functions.

> fully backwards compatible.

I wonder why you think it is "fully backwards compatible". Just like PEP 
575, you are changing the classes of certain objects. I think it's 
fairer to say that both PEP 575 and PEP 576 might cause minor backwards 
compatibility issues. I certainly don't think that PEP 576 is 
significantly more backwards compatible than PEP 575.

PS: in your PEP, you write "bound_method" but I guess you mean "method". 
PEP 575 proposes to rename "method" to "bound_method".


More information about the Python-Dev mailing list