[Python-3000] Fixing super anyone?
Phillip J. Eby
pje at telecommunity.com
Fri Apr 20 23:15:19 CEST 2007
At 10:06 PM 4/20/2007 +0200, Thomas Wouters wrote:
>It would only be a problem if the class decorator returns a wrapper class,
>rather than mutate the class. I guess we'd need a way to tell
>associated-functions "instead of ever visiting this class, visit this
>wrapper class instead. But don't mess with MRO"... I think. I'm not
>entirely sure how class decorators would affect MRO, really.
This depends somewhat, I think, on whether the conceptual translation of
super.foo is "super(ClassNameHere, self)" or "super(__thisclass__,
self)". If it is ClassNameHere, then the decorated class should be used;
if it's __thisclass__, there's a miniscule amount more argument for it
being the original class -- but even then, I think practicality probably
Meanwhile, I still think that cell (closure) variables are the One Obvious
Way to implement this. We can implement the super.foo syntax as an AST
transform to "super(..., firstarg)" where ... is either __thisclass__ or
ClassName, and then say that __thisclass__ or ClassName is then treated as
a cell variable defined in the surrounding scope.
In either case, we simply have the language definition say that the class
name or __thisclass__ (when used in a function inside a class) always
refers to the (decorated) class.
(Notice that this means there really isn't a need for the descriptor
association protocol, at least for Python's own use; I missed that in my
previous post, due to my enthusiasm for the independent merits of the
More information about the Python-3000