(original) (raw)
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
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
Sent: �9/�12/�2013 21:00
To: 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.\_\_\_\_ 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
\> 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.\_\_\_\_ 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