On 4/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 4/23/07, Adam Olsen <[EMAIL PROTECTED]> wrote: > > On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
