Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods
On 2018-04-24 14:53, Nick Coghlan wrote:
In PEP 575, I'm already proposing a flag (METH_ARG0_FUNCTION) to pass the function *instead* of self. Unless PEP 573 is rejected, maybe that should change to passing the function *in addition* to self.
That would definitely be an elegant way of addressing both use cases.
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. In any case, these things would be handled by Argument Clinic anyway, so it only matters if you are parsing arguments "by hand". Jeroen.
If PEP 575's new call doesn't have any surprising restrictions,
I think that completely dropping METH_METHOD would be the
best way of resolving this.
I suggest we push PEP 575 first and if it gets accepted, I will rebase
PEP 573 to these changes.
On Tue, Apr 24, 2018 at 4:34 PM, Jeroen Demeyer
On 2018-04-24 14:53, Nick Coghlan wrote:
In PEP 575, I'm already proposing a flag (METH_ARG0_FUNCTION) to pass the function *instead* of self. Unless PEP 573 is rejected, maybe that should change to passing the function *in addition* to self.
That would definitely be an elegant way of addressing both use cases.
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.
In any case, these things would be handled by Argument Clinic anyway, so it only matters if you are parsing arguments "by hand".
Jeroen. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/gmarcel.plch%40gmail.com
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. Jeroen.
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.
participants (3)
-
Jeroen Demeyer -
Marcel Plch -
Petr Viktorin