On 13 Sep, 2013, at 18:19, Steve Dower <[email protected]> wrote:
> From: Steven D'Aprano
>> On Fri, Sep 13, 2013 at 04:26:06AM +0000, Steve Dower wrote:
>>
>>> Last I checked, looking up in the instance dict us exactly what it
>>> does. Even the example you posted is doing that.
>>
>> The example from the PEP shows:
>>
>> return cls.__dict__[name]
>>
>> not "self.__dict__[name]". It is true that "the instance" in this case
>> refers to
>> it being an instance of the metaclass, but that instance is, in fact, a
>> class/type. That's why we normally call it "cls" in a metaclass method rather
>> than "self".
>
> Right, but where's the difference between these two?
>
> class A:
> def __tdb__(self, name):
> if name == 'some_attribute_on_my_instance_of_A':
> return its_value
> try:
> return self.__dict__[name]
> except KeyError:
> raise AttributeError(name)
>
> class MetaB:
> def __tdb__(cls, name):
> if name == 'some_attribute_on_my_class_B':
> return its_value
> try:
> return cls.__dict__[name]
> except KeyError:
> raise AttributeError(name)
>
> (Yes, either of these could be written with __getattribute__, but that
> function cannot be called by super().)
>
> As I see it, there are two (correct) ways to interpret what this method is
> for, which influences what it should be called.
>
> 1. It directly replaces obj.__dict__[name] everywhere that is done, including
> internally in the interpreter.
> 2. It is the same as __getattribute__ without the final call to
> object.__getattribute__
>
> I guess it's also correct to view it as a special helper for super(), but it
> is more generally applicable than that.
It directly replaces cls.__dict__[name] for object.__getattribute__ and
super.__getattribute__.
The primary reason for writing a proposal is that __getattribute__ can be used
to override attribute lookup on an instance, but there is way to override how
super() looks up an attribute. Using the method for both
super().__getattribute__ and object.__getattribute__ results in a cleaner model
than just having a new hook for super().__getattribute__.
>
> [...]
>
>> By the way, I think the PEP should have a more complex example. The
>> SillyObject
>> example is nice and easy to understand, but it doesn't really help with the
>> motivating use-case "dynamic classes that can grow new methods on demand".
>> Ronald, if you're reading this, can you add such an example please? Also,
>> there's a typo in the SillyObject M method ("fourtytwo" should not have a U
>> in
>> it).
>
> Agreed. No harm in more examples.
[...]
>
> A full example of where this may realistically be needed is longer and
> certainly involves metaclasses, but fundamentally it's just the same as
> __getattribute__ with slightly different semantics.
PyObjC will be a truly realistic example, but that involves loads of fairly
complex C code and likely won't help to explain anything beyond (hopefully)
showing that this proposal can lead to significant code removal in some
situations.
Ronald
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
