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 ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "LL YR VWL R BLNG T S" _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
