PEP 575 (Unifying function/method classes) update
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. Jeroen.
On 5 May 2018 at 18:55, Jeroen Demeyer <J.Demeyer@ugent.be> 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.
Thanks for this update Jeroen! If it doesn't come up otherwise, I'll try to claim one of the lightning talk slots at the Language Summit to discuss this with folks in person :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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.
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.
The PEP says:
User flags: METH_CUSTOM and METH_USRx These flags are meant for applications that want to use tp_methods for an extension type or m_methods for a module but that do not want the default built-in functions to be created. Those applications would set METH_CUSTOM. The application is also free to use METH_USR0, ..., METH_USR7 for its own purposes, for example to customize the creation of special function instances.
There is no immediate concrete use case, but we expect that tools which auto-generate functions or extension types may want to define custom flags. Given that it costs essentially nothing to have these flags, it seems like a good idea to allow it.
Why are these flags added? They aren't free – the space of available flags is not infinite. If something (Cython?) needs eight of them, it would be nice to mention the use case, at least as an example. What should Python do with a m_methods entry that has METH_CUSTOM set? Again it would be nice to have an example or use case.
participants (3)
-
Jeroen Demeyer -
Nick Coghlan -
Petr Viktorin