On Sunday, October 5, 2014 5:43:33 PM UTC-4, Guido van Rossum wrote:
This is a clever idea but I doubt it's worth adding.
The pattern proposed in the example in the first post doesn't strike me as very readable -- though you don't give any examples of *using* the decorator from the example, so it's a little difficult to imagine what the use case would be.
The idea is that I have a caller who is making changes to a network of nodes in steps. The caller tells the link to do phase 1, then makes some changes, then tells the link to do phase 2, then makes some changes, etc. Each time, the link can memoize some values from the network, send signals, etc. Therefore, I did not want to have the phases be different methods since the memos would then have to be stored on the object. Instead the phases are implemented using the generator pattern (that is, each phase is separated by yield) and the caller simply iterates over the generator as it makes its changes. The problem is that in addition to what is implemented by the method, the method wants to also delegate to super. So we need to iterate over the generator returned by the superclass. This pattern is easy to follow, but it would be nice to wrap that up in a decorator so that the method-writer can forget about this detail.
Adding __parent__ would have to happen as an extra pass once the class is defined -- the decorator (at least its outer part) runs at the time that the method is being defined as a plain function object, and at that time the class object hasn't been created yet. This also means that some decorators can't use the __parent__ attribute (because the outer function of the decorator runs before the object to be stored in __parent__ has been created).
Couldn't __parent__ be filled in when the class is complete by the default metaclass (is that just "type"?) The generator doesn't need to actually do anything with the parent member. The lookup is happening in the created method, so I think that's at call time, at which point the attribute will be filled in. I could have done the same thing with qualname, right?
If you really want to explore this idea further, you can probably define a metaclass that adds a __parent__ attribute to the function objects in the class __dict__ when the class is being created. Then you can experiment with using the pattern in some real code. Please report back here with some examples where the presence of __parent__ lets you write cleaner code.
The problem is that such a metaclass would add the member to the decorated method, and unfortunately, methods and functions don't have access to themselves and their attribtes at runtime as far as I know. So I'd have to look inside the members and add the __parent__ attribute to "method" attributes of the decorated methods, which is a bit weird.
An alternative that wouldn't even require a metaclass would be to write a helper function that looks the class object up by name after parsing __qualname__. There are some limitations to this, e.g. classes defined inside functions -- but that's already a suspect pattern anyway.
Yes, that works, but it really is very ugly to parse a string and then eval it.
On Sun, Oct 5, 2014 at 2:18 PM, Neil Girdhar <miste...@gmail.com <javascript:>> wrote:
On Sun, Oct 5, 2014 at 5:11 PM, Benjamin Peterson <benj...@python.org <javascript:>> wrote:
Neil Girdhar <mistersheik@...> writes:
On Sun, Oct 5, 2014 at 2:09 PM, Benjamin Peterson <benjamin <at>
python.org> wrote:
Neil Girdhar <mistersheik <at> ...> writes:
Many classes, functions, and modules are defined within the context
of another class, function, or module thereby forming a mathematical forest of declarations. It is possible to walk the descendants using __dict__ (for classes and modules), but not the ancestors. I propose adding __parent__ that would be filled at the same time that __qualname__ is filled in.This is unlikely to work. 1) It turns basically everything into a cycle.
Why a cycle?
Because, for example, the class would reference methods, which would reference the class.
Right. I don't see what's wrong with that. This already happens with the __module__ member and the module's immediate children.
2) __qualname__ is determined strictly from syntax, whereas __parent__
not be. For example, what happens if I take a method from one class and set it on another? __parent__ would not be well-defined.
I'm suggesting that parent be determined purely from declaration. If you copy something, neither qualname nor parent would change unless you change
could them.
It would mean your trick with super would only work for some methods.
It would only work for that are decorated in the usual way using @blah on methods defined in the class. If someone wants to copy that method somewhere else then they'll have to update __parent__ themselves.
_______________________________________________ Python-ideas mailing list Python...@python.org <javascript:> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
--
--- You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/python-ideas/94fTkAkjhCo/unsubscribe. To unsubscribe from this group and all its topics, send an email to python-ideas...@googlegroups.com <javascript:>. For more options, visit https://groups.google.com/d/optout.
_______________________________________________ Python-ideas mailing list Python...@python.org <javascript:> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)