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

[Guido van Rossum]

On Sun, Oct 5, 2014 at 7:51 PM, Neil Girdhar <mistersheik at gmail.com> wrote:

>
>
> 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.
>

I'm sorry, you'd have to point to the actual code if you want anyone to
make sense of that description. You are combining so many abstractions in
one paragraph that it feels like there must be lots of entirely different
ways to map the ideas to code, and you may well just have picked the wrong
way.


> 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"?)
>

I think that's what I was saying. :-)


>  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?
>

Eh? Anyway, __qualname__ does not have this problem -- the class *name* is
known by the time we get to 'def'.


> 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.
>

That's a fair point. But the default metaclass (i.e. type) would encounter
the same problem. So how *do* you imagine this should work? The fact
remains that the class isn't constructed until all the method definitions
have been executed, and the namespace in which the methods are defined is
what's passed to type() to construct the class object (with the class name
and the list of base classes).


> 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.
>

Which you should take as a hint that your problem is looking for a
different solution. :-)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141005/9786c340/attachment.html>