[Python-3000] auto-super()
Aahz
aahz at pythoncraft.com
Tue Apr 18 17:30:28 CEST 2006
On Tue, Apr 18, 2006, Thomas Wouters wrote:
>
> - Compiler hackery involving a magical variable name, say '__class__'
> or '__CLASS__'. The compiler would treat this specially, probably
> stored in the class dict, and type() (which is, after all, called to
> actually create the class) would stuff the actual class object in
> there. It causes a reference cycle, but all newstyle classes already
> do that ;P The main issue is that __CLASS__ would be new magic. It
> wouldn't exist when the class body is executed, and it would be a
> special form of enclosed variable afterwards (it should be extracted
> from the class namespace, using a similar mechanism as closures.)
It's not clear to me that this requires compiler hackery, just metaclass
hackery. Am I missing something?
Also, my idea is that self.super is a bound method/closure that already
contains a reference to the class. This makes dynamic classes more
difficult in some ways, but anyone who wants to play those sorts of games
should expect to do some magic mangling. If it's reasonably
well-documented, it wouldn't even be that difficult.
> - Fixing __-name-mangling so nameclashes don't occur, by using the
> 'fully qualified' classname in the mangling. The attribute wouldn't be
> accessible using normal attribute retrieval, but getattr() can get at
> it (and so can the C code, of course.) This has obvious repercussions,
> although I'm not sure if they're bad.
+1 Of course, we will still have name problems, but they won't be
clashes. I don't know that this is needed for the super() issue, but
there are other problems with the current mangling system.
--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/
"LL YR VWL R BLNG T S"
More information about the Python-3000
mailing list