[Python-Dev] PEP 573 -- Module State Access from C Extension Methods

[Petr Viktorin]

On 04/23/18 14:04, Jeroen Demeyer wrote:
> Hello,
> 
> I just saw this PEP. There is a bit of overlap between PEP 573 and PEP 
> 575 since these both change the calling convention for built-in methods. 
> In particular, PEP 575 also proposes to add a "defining class" member 
> (for different reasons). In PEP 575, this is added to the PyCFunction 
> struct itself instead of a separate struct PyCMethod.

The reason you just saw the pep is because it wasn't posted to 
python-dev yet, and it wasn't posted yet because we first want to look 
for potential conflicts with 573.

(There's no one forking on PEP 573 full-time, so unfortunately it's 
progressing slower than I'd like.)

> It would be nice to justify whether you really need a new class 
> (PyCMethod_Type) to support METH_METHOD. It looks strange to me that the 
> class of some object depends on an implementation detail like whether 
> METH_METHOD is specified.
> 
> The current PEP 573 implies that backwards compatibility concerns would 
> arise every time that METH_METHOD is added to an existing method. People 
> have asked questions on PEP 575 about that: it would break code 
> depending on "types.BuiltinFunctionType" for example. You could instead 
> just change PyCFunctionObject to add that field (that's what I did in 
> PEP 575).
> 
> For practical reasons, it would be nice to implement PEP 573 and PEP 575 
> together as they affect the same code (assuming that both PEPs are 
> accepted of course).

I currently even think PEP 575 can go forward *before* PEP 573. Having 
__objclass__ on methods of extension classes does sounds like a more 
elegant solution! And for PEP 573 it would mean one less annoying 
problem to solve.


Reading PEP 575, I miss an explanation of what __objclass__ *is* -- it 
only says the technical restrictions on it. For PEP 575 I found it 
pretty important that the reader gets a good mental picture of what it 
is, but it's a bit difficult to explain succinctly.
Maybe something like this would help make it clearer in PEP 573?

If set, `__objclass__` is the class that defines the method (which might 
be a superclass of `type(self)`). Functionally it's equivalent to the 
`__class__` cell [0] in Python code.

[0] 
https://docs.python.org/3/reference/datamodel.html#creating-the-class-object