<div dir="ltr"><div><div><div>This is a clever idea but I doubt it's worth adding.<br><br>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.<br><br></div>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).<br><br></div>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.<br><br></div>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.<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 5, 2014 at 2:18 PM, Neil Girdhar <span dir="ltr"><<a href="mailto:mistersheik@gmail.com" target="_blank">mistersheik@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sun, Oct 5, 2014 at 5:11 PM, Benjamin Peterson <span dir="ltr"><<a href="mailto:benjamin@python.org" target="_blank">benjamin@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Neil Girdhar <mistersheik@...> writes:<br>
<br>
><br>
><br>
><br>
> On Sun, Oct 5, 2014 at 2:09 PM, Benjamin Peterson <benjamin <at><br>
<a href="http://python.org" target="_blank">python.org</a>> wrote:<br>
<span>> Neil Girdhar <mistersheik <at> ...> writes:<br>
> ><br>
> > Many classes, functions, and modules are defined within the context of<br>
> another class, function, or module thereby forming a mathematical forest of<br>
> declarations.  It is possible to walk the descendants using __dict__ (for<br>
> classes and modules), but not the ancestors.  I propose adding __parent__<br>
> that would be filled at the same time that __qualname__ is filled in.This<br>
is unlikely to work.<br>
> 1) It turns basically everything into a cycle.<br>
><br>
><br>
> Why a cycle? <br>
<br>
</span>Because, for example, the class would reference methods, which would<br>
reference the class.<br></blockquote><div><br></div></span><div>Right.  I don't see what's wrong with that.  This already happens with the __module__ member and the module's immediate children.</div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
><br>
><br>
> 2) __qualname__ is determined strictly from syntax, whereas __parent__ could<br>
> not be. For example, what happens if I take a method from one class and set<br>
> it on another? __parent__ would not be well-defined.<br>
><br>
><br>
> I'm suggesting that parent be determined purely from declaration.  If you<br>
copy something, neither qualname nor parent would change unless you change<br>
them. <br>
<br>
</span>It would mean your trick with super would only work for some methods.<br></blockquote><div><br></div></span><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><span class=""><br>
<br>
<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a><br>
<br></span><span class="">
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group.<br>
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/python-ideas/94fTkAkjhCo/unsubscribe" target="_blank">https://groups.google.com/d/topic/python-ideas/94fTkAkjhCo/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href="mailto:python-ideas%2Bunsubscribe@googlegroups.com" target="_blank">python-ideas+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
</span></div></div></blockquote></div><br></div></div>
<br>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a><br></blockquote></div><br><br clear="all"><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div>