This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Rhamphoryncus
Date 2007-03-22.04:46:48
SpamBayes Score
Marked as misclassified
>> 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.
Date User Action Args
2007-08-23 14:52:37adminlinkissue1683368 messages
2007-08-23 14:52:37admincreate