[Python-3000] auto-super()

[Thomas Wouters]

On 4/17/06, Aahz <aahz at pythoncraft.com> wrote:
>
> On Sun, Apr 16, 2006, Michael P. Soulier wrote:
> > On 17/04/06 Greg Ewing said:
> >>
> >> The other possible reason for using super() is so you don't have
> >> to write the name of the base class into all your inherited method
> >> calls. But that's a separate issue that would be better addressed by
> >> a different mechanism, rather than conflating the two in super().
> >
> > Although you do have to put the current class name in the method
> > calls, as super() requires it as the first argument. I never
> > understood that. Why would I wish to use super(Bar) if I'm in class
> > Foo? Cannot Foo be implied here?
>
> Remember that in its current form super() is a regular function; it
> cannot be implied without stack hackery.  The autosuper metaclass should
> probably become part of the regular type metaclass in 3.0, but I think
> that requires a PEP -- and in keeping with Guido's recent admonishment,
> someone should probably try implementing it first and see what happens
> with the test suite.


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.

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:

 - 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)

 - 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.

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

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060418/b63c1994/attachment.htm