On 13 Sep, 2013, at 18:19, Steve Dower <Steve.Dower at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4