[Python-3000] Fixing super anyone? (original) (raw)

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