Stephen J. Turnbull writes:
> It may not be flexible, but it is quite useful. In most cases it's
> quite trivial to pick up the version from the second parent:
>
> class C(A, B):
> def foo(self, *args):
> return B.foo(self, *args)
> # we don't define bar() because we want C to inherit A's
> # version
This exemple shows, a dissymmetry between foo and bar, in cases A and B share a
parent P.
foo method only visits C, B then P
bar visits C, A, B, P
You'd need to return A.bar in C bar methods to get more symmetry, but what if
you wanted foo to visit the inheritance tree in this order?
C, B, A, P.
(While having bar visiting them in this order C, A, B, P) How would you go
about it?
> The questions are
>
> 1. Are there any "!#$%ing Python" cases that cannot be worked around?
> 2. How frequent are the "!#$%ing Python" cases compared to the Just
> Works cases?
> 3. How painful are the workarounds?
Actually, there's more questions to be asked.
I would add:
- Is there any problems at any steps of the programming experience (producing a
feature, debugging, testing, refactoring, logging, and so on)
I would argue the debugging experience in multiple scenarios i've presented are
horrible today, some refactoring aren't possible (more on that later), and
overall, the problem is the learning curve.
- For those problems, are the solution accessible to everyone?
Not everyone knows where to find docs, not everyone who finds docs knows how to
read it, not everyone who knows how to read it will understand it, and so on.
For the refactoring example, i believe it to be a good answer to your "Are
there any "!#$%ing Python" cases that cannot be worked around?"
Assume you're a lib author.
You're providing a few classes, let's say about cook's styles.
Each class has multiple methods, clean, slice, dice, mince, and so on.
Your lib turned out quite successful, and you've been requested to add a few
more cook's styles.
While adding those, you realise you're repeating a lot of the clean method, but
not all of it.
So, you refactor it, as you now identify a few cleaning styles.
You start from something like that:
```
class FrenchCook:
def clean(self):
print("baguette")
print("fromage")
print("european cleanning style")
class GermanCook:
def clean(self):
print("beer")
print("european cleanning style")
```
And end up with something like this.
```
class EuropeanCleaning:
def clean(self):
print("european cleanning style")
class FrenchCook(EuropeanCleaning):
def clean(self):
print("baguette")
print("fromage")
super().clean()
class GermanCook(EuropeanCleaning):
def clean(self):
print("beer")
super().clean()
```
Do you see the problem with this refactoring?
Keep in mind that your lib is used a lot, so any API change won't be
possitively received by your lib users.
Meaning composition is not an option.
If you can't see the problem with this refactoring, that's my point, because
there's one.
If you can see the problem with this refactoring, good for you. The problem is
still there.
Is there a refactoring that wouldn't exhibit this problem, yes.
This solution has it's own issues, that i'll talk about once you answer me.
i wouldn't wanna spoil the exercice by giving you the answer.
Actually, this could be one question i'll add into the form i'm getting ready.
I'll give it to you all so we can agree on the fairness of the questions first,
and stuff like that, before running it.
> That doesn't "look like" a mixin, though. That looks like a simple
> inheritance chain
Our experiences with mixins seems very different, i've consistently seen them
used as a way to "extend" the not mixin class behavior.
The adoption syntax i propose *is* a simple inheritance chain (in this
exemple), and that's the goal.
Mixins in your experience seems to be a lot more 'compositional' and for them,
my proposal wouldn't change much.
They would still be used the same way.
There would be one major difference, which is that when multiple mixins provide
the same attribute / method, accessing this attrribute / method would raise an
ExplicitResolutionRequired error, instead of leaving it be just like that.
That would reduce the risk of missing that possible error, and make the error
actually related to the source of the error.
Solutions to fix this errors aren't hard to provide : either mixins need to
rename their attributes / method with a double underscore at first, or the
mixin user can just redefine the method / select which to use, by assigning the
mixin.method to the class method.
_______________________________________________
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/JTDXDWPA32LPPFHUMVMSQZWOXWHMTXLX/
Code of Conduct: http://python.org/psf/codeofconduct/
