[Python-Dev] PEP 573 -- Module State Access from C Extension Methods (original) (raw)
Petr Viktorin encukou at gmail.com
Wed Apr 25 14:33:09 EDT 2018
- Previous message (by thread): [Python-Dev] PEP 573 -- Module State Access from C Extension Methods
- Next message (by thread): [Python-Dev] PEP 573 -- Module State Access from C Extension Methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 04/24/18 13:12, Jeroen Demeyer wrote:
On 2018-04-24 16:34, Jeroen Demeyer wrote:
On the other hand, if you are passing the function object, then you can get self from it (unless it's an unbound method: in that case self is NULL and self is really args[0]). So there wouldn't be a need for passing "self". I'm not saying that this is better than passing "self" explicitly... I haven't yet decided what is best. One thing I realized from PEP 573: the fact that self for built-in functions is set to the module is considered a feature. I never understood the reason for it (and I don't know if the original reason was the same as the reason in PEP 573). If we want to continue supporting that and we also want to support get for built-in functions (to make them act as methods), then there are really two "selfs": there is the "self" from the method (the object that it's bound to) and the "self" from the built-in function (the module). To support that, passing both the function and "self" seems like the best way.
You're talking about functions with METH_BINDING here, right? There the other "self" would be the defining module. It might make sense to pass that also in the struct, rather than as an additional argument. Perhaps "m_objclass" could point to the module in this case, or a new pointer could be added.
- Previous message (by thread): [Python-Dev] PEP 573 -- Module State Access from C Extension Methods
- Next message (by thread): [Python-Dev] PEP 573 -- Module State Access from C Extension Methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]