[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 
beats purity.

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

More information about the Python-3000 mailing list