[Python-Dev] PEP 447: add type.locallookup (original) (raw)

Steven D'Aprano steve at pearwood.info
Fri Sep 13 08:52:38 CEST 2013

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).(B, 'F'). So the objects being used are:

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 method is called on the metaclass) or the class B (which ends up as the first argument to the 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

More information about the Python-Dev mailing list