super - is (should) it (be) a reserved word?

[Alex Martelli]

"Thomas Gagne" <tgagne at ix.netcom.com> wrote in message
news:39DEAD1A.1201A557 at ix.netcom.com...
> Alex Martelli wrote:
>
> > "Grant Edwards" <ge at nowhere.none> wrote in message
> > news:wAqD5.4401$WJ3.791257 at ptah.visi.com...
> >     [snip]
> > > Personally, I would like some way to refer to _a_ superclass.
> > > If there's more than one, it's an error or undefined or
> > > arbitrarily picks one. Almost all of the code I see/write uses
> >
> > self.__class__.__bases__[0] satisfies this request, I think.
> >
> > Would the saving of about three characters to call it, say,
> > self.__class__.__super__ be worth introducing a 'shortcut'...?
> >
> > Alex
>
> Three characters wouldn't be enough of a shortcut.  I really ought to be
> something as short as 'super', which says all it needs to.  I supposed
I've

You really mean "super", rather than self.__class__.super?  EVERY
access to an attribute of self goes through self.something, *except*
for your new invention which has so MUCH more importance than
anything else already existing or still to be invented in Python, that
it deserves breaking half the rules, conventions, and principles of the
language, such as "explicit is better than implicit"...?

The leading and trailing underlines are "negotiable" -- they're just
usual for semi-magic stuff having to do with implementation, not
essential.  But the explicit naming of self isn't.  Python always, but
always, requires it.  All sort of good effects follow, and the "cost"
of typing in the 'extra' "self." is really minor -- if it's a cost at all (I
come from languages which implicitly scope to self, Current, this,
yet I now much prefer the explicitness, originated I believe in
Modula-3 and also adopted by Python).

If you accept this, then you don't really need a Python language mod
to support your favourite style (frequent access to "_a_ superclass",
as you put it); just place, in your site.py if need be, a:

def sup(x):
    return x.__class__.__bases__[0]

Now, you can write sup(self) wherever you wish -- just 4 characters
more than bare 'super', and one less than self.super...  If, within a
certain method, you use this more than once or twice, then you can
also optionally have an initial line of
    super=sup(self)
and use the local-variable super thereafter to your heart's content.

Note that in each of this cases super is a CLASS, not an INSTANCE.
I suspect this deep-semantic issue is somewhat more important
than the syntax-sugary one of whether you need to type 5 or 7
characters, no?-)  But, we can remedy that (see later...).

> never found much need for multiple inheritance (except maybe in GP) but
not in
> the planned ecologies which are the programs I write.

Mixin-classes are good, and a very elegant and concise approach
for many things.  For example, you could use one to have self.super
(in this exact syntax-sugar form) in any class that inherits from
WithSuper (not intended to be used as the FIRST baseclass...):


import new

class WithSuper:
    def __init__(self, *args, **keywords):
        self.super=new.instance(self.__class__.__bases__[0], self.__dict__)
        self.super.__init__(*args, **keywords)

class A:
    def __init__(self):
        self.a=23
    def dotry(self):
        print self.a

class B(A, WithSuper):
    def __init__(self):
        WithSuper.__init__(self)
        self.b=45
    def dotry(self):
        print self.b
        self.super.dotry()


Note that, here, we've also fixed the semantic.issue -- self.super is an
instance, equivalent to self, except that its class is the first base of
self's own class.  (This uses Python 2.0 for access to the new module
and pass-through of arguments and keywords from WithSuper to the
real super's __init__ methods; it would be clunkier though possible to
do in older Python versions).

Certain things that are hard to do otherwise become a snap with
the mixin style.


> I like the idea of 'super' being useful when there's single inheritence,
and
> its behavior being undefined, or even an error, when thee are multiples.

In (e.g.) WithSuper's __init__, you could well test explicitly that the
self object has exactly two direct bases -- the semantic/true one, and
WithSuper itself -- and raise an explicit exception otherwise.  I think,
however, it would be wiser to sanction by convention that a class in
your programming style has one "real" (semantic, true) baseclass and
N (1 upwards) "mixin" ones; thus you avoid boxing yourself in for
the possible future time when you find other handy uses of mixins.

self.super refers to the semantic-base which by convention is always
listed first (makes sense, and consonates with the use of metaclass
protocol if you do that)...

So, will you place in your site.py the half a dozen lines needed to
have the WithSuper mixin class always available...?

[Personally, I find Python's ease of metaprogramming one of its
many strengths; it comes chiefly from its simplicity and systematic
use of explicit idioms rather than "black magic" implicit ones, as
well of course from the huge wisdom of our benevolent dictator
for life and his chosen "they few, they happy few, they band of
brothers"...].


Alex