[Python-Dev] PEP 575 (Unifying function/method classes) update

Petr Viktorin encukou at gmail.com
Mon May 14 13:56:56 EDT 2018


On 05/05/18 04:55, Jeroen Demeyer wrote:
> Hello all,
> 
> I have updated PEP 575 in response to some posts on this mailing list 
> and to some discussions in person with the core Cython developers.
> See https://www.python.org/dev/peps/pep-0575/
> 
> The main differences with respect to the previous version are:
> 
> * "builtin_function" was renamed to "cfunction". Since we are changing 
> the name anyway, "cfunction" looked like a better choice because the 
> word "built-in" typically refers to things from the builtins module.
> 
> * defined_function now only defines an API (it must support all 
> attributes that a Python function has) without specifying the 
> implementation.
> 
> * The "Two-phase Implementation" proposal for better backwards 
> compatibility has been expanded and now offers 100% backwards 
> compatibility for the classes and for the inspect functions.


Hi,
I'm reading the PEP thoroughly, trying to "swap it into my brain" for 
the next few days.
It does quite a lot of things, and the changes are all intertwined, 
which will make it hard to get reviewed and accepted.
Are there parts that can be left to a subsequent PEP, to simplify the 
document (and implementation)?
It seems to me that the current complexity is (partly) due to the fact 
that how functions are *called* is tied to how they are *introspected*. 
Perhaps starting to separate that is a better way to untangle things 
than arranging a class hierarchy?


Can the problem of allowing introspection ("It is currently not possible 
to implement a function efficiently in C (only built-in functions can do 
that) while still allowing introspection like inspect.signature or 
inspect.getsourcefile (only Python functions can do that)") be solved in 
a better way?

Maybe we can change `inspect` to use duck-typing instead of isinstance? 
Then, if built-in functions were subclassable, Cython functions could 
need to provide appropriate __code__/__defaults__/__kwdefaults__ 
attributes that inspect would pick up.
Maybe we could eve add more attributes (__isgenerator__?) to separate 
how a function is called from how it should be introspected -- e.g. make 
inspect not consult co_flags.




More information about the Python-Dev mailing list