On 9/12/19 10:56 PM, Neil Schemenauer wrote:
On 2019-09-12, Petr Viktorin wrote:
On 9/12/19 9:05 PM, Neil Schemenauer wrote:
Slots like np_add could lookup the PyFunction analog and call it.
Where would they look it up?
I think either in tp_dict or you can have a table of object pointers indexed by slot ID.
tp_dict of what? Py_TYPE(self) doesn't work for subclasses.
That object has the reference to the module namespace, just like a PyFunction object does. When the module is first created, you allocate heap objects for each of the PyFunction object thingies and bind them to the module.
Why to the module, and not to the type object (which is bound to the module)?
To match the way PyFunction works. It has a reference to the module global namespace (i.e. __globals__). Likewise, functions defined in an extension module should have a reference to their global namespace.
The binding of a method to the type object should be done by the descriptor. That will make methods implemented in native Python code work similar to methods implemented by C code.
For normal methods, it's almost what PEP 573 does: I don't see much difference between this and storing the *type* with the PyFunction, and passing the type to the C code, which can then access the module state from the type.
For slots, this sounds like a way forward. There's quite a lot practical complications, though, so PEP 573 does not really address slots -- aside from the PyType_DefiningTypeFromSlotFunc crutch, which doesn't pretend to be a very good solution, but it's a very simple one that's available now. (If *that* is where PEP 573 strikes you as inelegant but expedient, then we agree. My educated guess is that an elegant alternative to this will take years to design and implement, and will be largely orthogonal to the rest of PEP 573.)
Sorry, but I don't see what you mean by "making things look the same". Do you want to get source/tracebacks from C code? Have C code be as dynamic (and full of slow checks) as Python?
No, I'm talking about looking up functions and methods and calling them. I want the fact that they are implemented in Python or in C to be encapulated more than it currently is.
PEP 573 doesn't change how methods are looked up. They're looked up on the instance, which normally delegates to the type and its superclasses. The changes in PEP 573 are:
- the type object is passed to the C code
- the type object has a reference to its defining class, which has a reference to the module (All of that is opt-in for backwards compatibility)
Do you want to write a PEP for that?
I suppose I could try. While I think the idea should work, there many details to work out. Maybe there is some fatal flaw.
PEP 573 has a fairly complete proof of concept implementation, so I'm fairly sure it doesn't have fatal flaws. (It does have deliberate omissions, though.)