[Python-Dev] PEP 447: add type.__locallookup__

[Steve Dower]

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:steve at pearwood.info>
Sent: ‎9/‎12/‎2013 21:00
To: python-dev at python.org<mailto:python-dev at 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 at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130913/fec6fd3c/attachment-0001.html>