On 13 Sep, 2013, at 18:19, Steve Dower <steve.do...@microsoft.com> 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
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to