[Python-3000] Fixing super anyone?

Adam Olsen rhamph at gmail.com
Tue Apr 24 02:41:44 CEST 2007


On 4/23/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 4/23/07, Adam Olsen <rhamph at gmail.com> wrote:
> > On 4/23/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > > But I can't say I particularly like this idea, compared to "super.foo" or
> > > even "super(self).foo".  In fact, the latter invocation doesn't even
> > > require a keyword -- it just means the compiler needs to include a cell
> > > variable for the current class whenever it thinks you might be using super().
>
> > +1 on super(self).foo.  It's SomeLongClassName we want to get rid of, not self.
>
> It won't normally be for an attribute.  Typically, it would look like:
>
>     super(self).foo(arg1, arg2)
>
> or even
>
>     super(self).foo()
>
> I'm not sure that is much improvement over explicitly showing the
> class, though it is certainly an improvement over using the
> (rebindable) class name.
>
> > As a bonus, super() and super(cls) have obvious semantics.
>
> What would they be?  Are you assuming that the two-argument forms
> would go away?  Or that the *first* positional argument could be
> defaulted to __this_class__, but the second would be mandatory?

Err.. yes?  Actually I assumed that there'd be both the old
two-argument forms and the new implicit __this_class__ form, but in
hindsight that's obvious ambiguous.

Although I don't understand the purpose of the old super(type) option,
so maybe that can be deleted to remove the ambiguity.

-- 
Adam Olsen, aka Rhamphoryncus


More information about the Python-3000 mailing list