On 13 Sep, 2013, at 18:19, Steve Dower <Steve.Dower@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