On Jan 13, 3:31 pm, thebjorn <[EMAIL PROTECTED]>
wrote:
> They do, except for when it comes to what super(..) returns. It isn't
> really an object in the sense that they're presented in the tutorial,
> but rather a sort of proxy to the methods in the ancestor classes of
> the concrete object (self), relative to the current method's class. I
> can't imagine that sentence would ease any confusion however, suffice
> it to say that you have to call getattr(super(..), 'name') instead of
> super(..).__getattr__('name') and you have to call super(..).__len__()
> instead of len(super(..)) -- I can't imagine that lessens any
> confusion either :-/
Surprisingly, I think your first sentence *does* make something more
clear. Let me check if I understand it right: when we call a method on
super(Foo, self) it is as if we were calling call-next-method in
Common Lisp or Dylan (i.e. the method of the class on the right of Foo
in self.mro()). This however does not imply for super to have its dict
the same as the class on the right of Foo---it remains the same as
self's dict.
However, there's one piece that doesn't completely fit to the puzzle:
why does getattr work? The help says:
getattr(...)
getattr(object, name[, default]) -> value
Get a named attribute from an object; getattr(x, 'y') is
equivalent to x.y.
When a default argument is given, it is returned when the
attribute doesn't
exist; without it, an exception is raised in that case.
Does it work on the basis that "getattr(x, 'y') is equivalent to x.y"?
What is then a "named attribute for an object" in Python? It seems not
to be equivalent to the value of the item whose name is 'y' in the
object's class __dict__...
Cheers,
-- Richard
--
http://mail.python.org/mailman/listinfo/python-list
