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
_______________________________________________
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
