Last I checked, looking up in the instance dict us exactly what it does. Even the example you posted is doing that. And the only difference from __getattribute__ is that it throws instead of following the MRO, which is intended to allow base classes (via super, and another call to this method) to dynamically respond to a getattr without the cooperation of subclasses.
Consider class A, which knows it has a method F, but will not create it until the first __getattribute__ call. Now class B derives from A, and someone calls super(B).F(obj). Currently, super only looks in __dict__ for F, which will fail to invoke A.__getattribute__. Because super is used to provide MRO traversal, it can't rely on B.__getattribute__ to perform the traversal, so it currently has no choice. The PEP was originally adding a special class method to provide a __getattribute__ equivalent that would not traverse the MRO, so that super could use it and people can create dynamic classes that can act as base classes. I pointed out that this could be an instance method (thereby avoid automatic-classmethod magic) and implemented on a metaclass for the class behavior. Unless the PEP has changed recently, this is still an instance method that will look up members defined directly on the type and not on base classes. There may still be valid questions to answer (such as, should overrides if this method on base classes be inherited), but whether it is a type/class method is no longer one of those. Cheers, Steve Sent from my Windows Phone ________________________________ From: Steven D'Aprano<mailto:st...@pearwood.info> Sent: 9/12/2013 21:00 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] PEP 447: add type.__locallookup__ On Fri, Sep 13, 2013 at 03:04:49AM +0000, Steve Dower wrote: > What about __getlocalattribute__ or __getattributenorecurse__? Long, > but this isn't going to be used often. This has nothing to do with locals, nor does it have anything to do with recursion, so both those names are misleading. > Putting "type" or "class" in the name would be misleading. It's an > instance method (that is most useful when implemented on a metaclass). Regardless of whether it is an instance method or not, by default it performs the lookup on the type. Hence the C function _PyType_Lookup and hence my suggestion __typelookup__. But I think that __typelookup__ does describe quite well what the method does. It looks up on the type. The PEP is fairly clear on how this is supposed to work, e.g. the default type.__<whatever>__ method will look up in the class/type dict. PEP 447 includes an example of how you might implement this in Python: class MetaType(type): def __locallookup__(cls, name): try: return cls.__dict__[name] except KeyError: raise AttributeError(name) from None "local lookup" doesn't even come close to describing what the method does or why you would use it. It suggests something to do with locals, which is not the case. Neither does __getattributenorecurse__, which suggests looking up an attribute on an object without following the inheritance hierarchy, e.g. looking in the instance __dict__ but not the class __dict__. So the complete opposite of what it actually does. -- Steven _______________________________________________ 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/steve.dower%40microsoft.com
_______________________________________________ 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
