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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4