super() doesn't get superclass

[Neil Cerutti]

On 2007-09-19, Michele Simionato <michele.simionato at gmail.com> wrote:
> On Sep 19, 3:22 pm, Sion Arrowsmith <si... at chiark.greenend.org.uk>
> wrote:
>> Ben Finney  <bignose+hates-s... at benfinney.id.au> wrote:
>>
>> > If a function is named 'super' and operates on
>> >classes, it's a pretty strong implication that it's about
>> >superclasses.
>>
>> But it doesn't (under normal circumstances) operate on classes.
>> It operates on an *instance*. And what you get back is a (proxy
>> to) a superclass/ancestor of the *instance*.
>>
>> (And in the super(A, B) case, you get a superclass/ancestor of
>> *B*. As has just been said somewhere very near here, what is
>> misleading is the prominence of A, which isn't really the most
>> important class involved.)
>>
>
> Happily A (and B too) will become invisible in Python 3000.

Nobody will miss A, but doesn't making B invisible recreate the
current mystery in a new form? We want to get rid of A because it
isn't possible to avoid repeating ourselves. But self is usually
easily available and helps define what's happening.

  super.foo()

to me, is even more confusing.

  self.super.foo()

or

  super(self).foo()

seem like improvements. Unfortunately, neither is one of the
current alternate proposals. The closest competing proposal in
PEP3135 is:

  self.__super__.foo()

That syntax seems justified given the specialized application and
involved pitfalls of super that you disclosed in your article.

-- 
Neil Cerutti
These people haven't seen the last of my face. If I go down, I'm going down
standing up. --Chuck Person