<br><div><span class="gmail_quote">On 4/17/06, <b class="gmail_sendername">Aahz</b> <<a href="mailto:aahz@pythoncraft.com">aahz@pythoncraft.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sun, Apr 16, 2006, Michael P. Soulier wrote:<br>> On 17/04/06 Greg Ewing said:<br>>><br>>> The other possible reason for using super() is so you don't have<br>>> to write the name of the base class into all your inherited method
<br>>> calls. But that's a separate issue that would be better addressed by<br>>> a different mechanism, rather than conflating the two in super().<br>><br>> Although you do have to put the current class name in the method
<br>> calls, as super() requires it as the first argument. I never<br>> understood that. Why would I wish to use super(Bar) if I'm in class<br>> Foo? Cannot Foo be implied here?<br><br>Remember that in its current form super() is a regular function; it
<br>cannot be implied without stack hackery. The autosuper metaclass should<br>probably become part of the regular type metaclass in 3.0, but I think<br>that requires a PEP -- and in keeping with Guido's recent admonishment,
<br>someone should probably try implementing it first and see what happens<br>with the test suite.</blockquote><div><br>The autosuper class (and any other class that tries to do the same thing the same way) has a serious problem (which it inherits from name-mangled attrs): nameclashes. I usually use an autosuper-style metaclass (which also does auto-class/staticmethoding and autopropping) that explicitly prohibits subclasses with the same name, but I can only do that because I tend to control the entire class hierarchy. I wouldn't want to use it in public code, certainly not for common baseclasses.
<br></div><br></div>I'm in favour of super(). The arguments against super() are understandable -- if you only think about your own class, or completely disregard MI. I think that's irresponsible: super() always calls the right baseclass method, even if it changes its signature. If your class ends up being used in MI *and* changing baseclass signatures (in unexpected order), it will break with super() just as hard as without super(), but not vice versa ;) I'd really like an easier way to spell super() in
3.0 (or 2.6), as well as have super() support old-style classes. The ideas I've so far come up with:<br><br> - 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.) There's also the conceptually new idea of a variable having a static, compile-time meaning, inviting suggestions for __FILE__ and __LINE__ (which are actually easy to implement ;P)
<br><br> - 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.
<br><br>I've also considered stackframe hackery to get at the desired class from super(), or retroactively patching all methods of a class to have a 'my class' attribute or variable, but those won't work (as Guido exlained.)
<br><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!