>> I think it would also help if calling a method via super() didn't allow
>> positional arguments.
>
> That's absurd, *except* for __init__(), where it could make sense
> depending on the style of cooperation used.  But not enough to enforce this
> in the language; in Py3k you will be able to enforce this on a per-class
> basis.

The vast majority of "positional" arguments can also be given via name.  The rare exceptions (primarily C functions) may not cooperate well anyway, so you're trading a relatively obscure limitation for better error detection.

Perhaps not that important though, since it could be taught as bad style unless absolutely needed.


>> Having two mixins with the same method name and
>> without a common parent class is just not sane.
>
> Right.  This is a cornerstone of cooperative multiple inheritance that
> sometimes seems to be forgotten; there is a big difference between defining
> a method and extending a method, and only extending methods can make super
> calls.
>
> The __init__ case is an exception, because there's no requirement that a
> subclass have a signature compatible with the superclass (if you don't get
> this, read up on constructors in C++ or Java).

I understand the desire for it to be an exception, I fail to see how it actually is one.  The namespace/signature conflicts exist just the same.

The only way I can see to handle incompatible signatures is to add a flag that says "I am the *ONLY* class allowed to subclass X" (triggering an error if violated), have super() entirely bypass it, and then call X.__init__() directly.  Even that doesn't handle X's superclasses being subclassed more than once, and it looks pretty complicated/obscure anyway.