Greg Ewing writes:
> It does this because the way it's intended to be used is to
> pass it the class in which the method you're calling it from is
> defined.
It doesn't really matter what's the intended way for it to be used tho, what
matters when it comes to designing / updating the design of a feature is how
people are using it today, and what people expect it to do naturally.
Taking this into account is the easiest way to make an intuitive feature.
The way it is intended to be used as virtually no value (when it comes to
designing / updating the design of a feature).
And updating the super feature(s) is what i'm proposing here.
> Now that
> we have argumentless super, there's no longer any need to do
> that [pass argument to super].
Some exemple i give including, but not limited to the gobelin exemple are a
fair use case in which you'd want to use the argumented version of super. The
fact that today's super doesn't work in those scenario just means super doesn't
work in all scenarios, I believe the scenarios i built to be fairly consistent
with the average developper expectation of super's behavior, based on acquired
knowledge on use of super in the general cases.
> If you're
> using super at all with MI, your methods should all be designed
> so that it *doesn't matter* exactly what order they get called in
This doesn't match the mixin case, which is the most common use today for ML.
Essentially, in this case, you have a collection of parent class, all of which
would benefit from having the same variant child class.
The exemple i always give : you have multiple view class, you have the
permission mixin, so you (as a lib author) wanna provide all possible
combinations of simple view class, and permission mixin augmented view class.
today's only (reasonable) way is ML.
```
class MyView(Permission, View): ...
```
This explicitely rely by design on the fact that permission comes before view.
I'd argue this is a case of "I can't declare inheritance at definition, and I
can't declare it later either, so we have to resort to ML"
And this is covered by my adoption proposal, which allows for setting
inheritance relationship in the MyView class.
```
class MyView(
Permission(
View
)
):
...
```
But I agree with the feeling that you should not expect an order between the
parents.
And essentially, if i get you right here, you're saying that ML should be
designed (when we use it, at least) so that we could reorder the parent in the
class definition, and it wouldn't matter, wouldn't break anything.
Essentially, (i'm talking about what i understand you consider a properly
designed ML scenario):
```
class A(P1,P2): ...
```
Is 100% equivalent of
```
class A(P2,P1): ...
```
correct me if i'm wrong.
My proposal makes this an explicit feature of ML.
As you have to think of a lot of things to make it work this way today, and
this would be the default with my proposal.
And as mentionned, there are cases that simply can't work this way.
Also, i do wanna mention that you do in fact care, to some extent to which
order things are called in.
Not always, but in some cases you do, and not being able to target one of the
parent first, instead of the default one, when the default one is not
appropriate is a problem.
Essentially, if for any reasons today, MRO is not consistently the good order
for you, all you can do is forget about it.
When really, there's no reason (not in term of UX i mean) to be so opinionated.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FUY2CIUNIPJ6DXCTQAPD5FPJ4V5532IM/
Code of Conduct: http://python.org/psf/codeofconduct/
