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 J.Demeyer@ugent.be wrote:
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.
-
Jeroen Demeyer -
Marcel Plch -
Petr Viktorin