[Python-ideas] Add __parent__ to all classes, functions, and modules

[Neil Girdhar]

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... at gmail.com 
> <javascript:>> wrote:
>
>>
>>
>> On Sun, Oct 5, 2014 at 5:11 PM, Benjamin Peterson <benj... at python.org 
>> <javascript:>> wrote:
>>
>>> Neil Girdhar <mistersheik at ...> 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__ 
>>> could
>>> > 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
>>> 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... at 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... at googlegroups.com <javascript:>.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python... at 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) 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141005/09b865f6/attachment.html>