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

[Petr Viktorin]

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.