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

[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".

I was reacting to your statement that [quote]Putting "type" or "class" 
in the name would be misleading[end quote]. I don't believe it is 
misleading. "type lookup" is exactly what it does: it does a lookup on a 
type. Take your example below:

> 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). 

[Aside: I'm not sure why you are using an unbound super object super(B) 
instead of the more usual super(B, obj).F(). Have I missed something?]

As I understand it, that ends up calling type(B).__<whatever>__(B, 'F'). 
So the objects being used are:

- the metaclass type(B);
- the class B

but not the instance self = B(), even though F is a regular instance 
method on A that ends up seeing self as the first argument.

Given this, I believe that "lookup on the type" is exactly what the 
method does, whether you interpret "the type" as the metaclass (the 
__<whatever>__ method is called on the metaclass) or the class B (which 
ends up as the first argument to the <whatever> method).


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).


[...]
> 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.

I don't believe that anyone is arguing that it should be a class method. 
I'm certainly not. But even if somebody is, that doesn't have anything 
to do with the name. We write dict.fromkeys(), not dict.typefromkeys().



-- 
Steven