Brendan Barnwell writes:
> You seem to be envisioning a system in which multiple inheritance
> gives a subclass a "menu" of behaviors from which it may explicitly choose,
> but does not actually combine the superclasses' behaviors into a single,
> definite behavior of the subclass. In that scheme, order of multiple
> inheritance would not matter, because the superclasses don't need to be
> "integrated" into the subclass; they just sit there waiting for the
> subclass to explicitly decide which superclass it wants to delegate to.
not sure i had time to answer this one yet, so here we are.
I do not want any change in case of simple inheritance, nor do i want any
change in case of MI where there's no name collision.
The integration of parent class would be the exact same in those cases.
And if you doubt it, my proposal, about method resolution, is that if there's
only one candidate for resolution, we select it, if there's none, we raise the
standard attribute error, and if there's multiple, we raise an explicitness
required error.
In case of MI where there's no name collision, aka, there's never more than one
candidate for resolution, the behavior would be the exact same.
Expliciteness is required only in case there's multiple candidates for
resolution.
Also, super, or the equivalent i named __as_parent__ in my poc, would be able
to target the parent class it's given as an argument, as well as implicitely
chose the only parent, when there's only one parent.
Order of the parent doesn't matter, because we just don't need it anymore. Not
because we're not integrating the parents.
> they just sit there waiting for the
> subclass to explicitly decide which superclass it wants to delegate to.
Implicitness would still be the overall norm.
> When a subclass inherits from multiple superclasses, the
> superclass behaviors are *combined* into a *single* set of behaviors for
> the subclass. They're not "held separate" somehow as alternative
> inheritance hierarchies; they are joined into one.
Demonstrably false:
```
class Dad:
age = 65
class Mom:
age = 61
class Son(Dad, Mom):
pass
```
Son.age is definitely not a combination of Dad's and Mom's age
Same apply for methods, they only "combine" assuming Dad's method calls super.
Which it's likely not to if it's meant to run independant instances, as it
doesn't have parent itself.
But it is possible to have those behavior combine, yeah.
> They're not "held separate" somehow as alternative
> inheritance hierarchies; they are joined into one.
All but one are ignored, and that one has the responsibility to care about the
others.
The design i propose would make the responsibility of "caring" about all its
parent to the class inheriting from them.
Which localises the responsibility a bit better i think, and definitely allows
for actual integration of multiple class into one, at least as well as today's
solution.
There's probably a joke about parents ignoring conflict so much it leads to
divorce somewhere in there.
> I don't want to sound harsh, but if `class A(B,
> C)` doesn't "feel" different to you from `class(C, B)` then I think you
> need to adjust your feelings rather than expect Python to adjust its
> behavior.
You're absolutely not harsh, you're actually quite respectful. Disagrement is
not an insult.
I think that python is (at least know to be) a language that cares about making
it the easiest to program.
Or that it's made to be easy to learn.
Essentially, that it always cared about having a very reliable UX design, not
that it named it UX design, but that's at the core of python values.
I believe the change i propose goes very well with those values / goals of
python, and wouldn't be out of place in python.
I don't believe it's as clear cut as you say it is, honestly.
As much as i understand the feeling 'perhaps its time you learn', i don't
believe it applies here, since it's a commonly misunderstood feature. If i were
the actual only one guy who didn't understand it, sure. But that's not the
case. And at some point, we gotta look at the feature itself.
_______________________________________________
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/G7EEFAWMODTAUZKW63VRJANEG2CU5B7B/
Code of Conduct: http://python.org/psf/codeofconduct/
