Hi,
Before anything, i made a github repository about this topic here :
https://github.com/malmiteria/super-alternative-to-super
The core of what i wanna discuss here is that i don't think mro and super
(mainly because it relies on mro) are very pythonic. Mainly that some behaviors
of th
i mean yeah, of course you don't need super.
And i also understand that feeling that composition is better than inheritance.
But that's beside my point, super acts as a proxy to a parent, and is by
default the feature to refer a parent from within a class method.
This is the feature that i think
I'm aware that 'class.method' works, but this doesn't give the same proxy
feature super does.
But in essence, i disagree it's the most correct way to do it. I think it's
very likely the most correct *automatic* way of doing it tho. And that's my
point, why does it have to be automatic?
Also, i
the alternative to super really is not the important part of my proposal, it's
the alternative to MRO.
An example of a case where i genuinly believe my solution adds value is this :
```
class A:
def method(self):
print("A")
class B:
def method(self):
print("B")
class C(
t__(A).call_me_in_B_first()
```
the __as_parent__ is the name i gave my alternative to super in my github
repository : https://github.com/malmiteria/super-alternative-to-super (and yes,
you can run that code for yourself, i've included ~100 tests to showcase
different behaviors)
And yeah, th
> To me it doesn't seem reasonable that someone would inherit from two
> classes and want to call a method from one without even knowing that
> there's a method name collision. If you're going to inherit from A and
> B, you need to know what methods they provide and you need to think
> about t
ly the punchline.
It makes sense that a child is more specific than its parents.
It doesn't make sense that any parent would be more specific than any others
(at the same depth at least).
That's what my alternative does, i've coded it already, you can take a look at
it : https://github
he correct solution in my
mind.
I tested it on multiple inheritance trees, and mixed with current style MRO +
super, this doesn't seem to lead to issues.
You can find all the tests i've done in the test folder here :
https://github.com/malmiteria/super-alternative-to-super
Again, why
> because that's the entire point of super() -- if you don't want automatic,
> do what you want by making direct method calls.
Yeah, but current solution is very unknown to most programmers, so they
wouldn't know before hand to do that.
My solution provides a direct message to the developper tell
urrent solution in case
simple inheritance, and that i've tested it thoroughly in what i assume is all
the possible cases, given the set of rules i decided for my Explicit Method
Resolution.
Feel free to take a look at it here :
https://github.com/malmiteria/super-alternative-to-super and
k what i'm looking for is different from inheritence, i think it's
more a variant of the current way of doing things.
Feel free to take a look at the readme of my github repository where i dive in
some depths into my reasoning here :
https://github.com/malmiteria/super-alternative-to-super
class decorator aren't propagated through inheritance, so i just made it with a
good ol' parent class.
again, feel free to take a look at my implementation of it here:
https://github.com/malmiteria/super-alternative-to-super
It's thorougly tested, and hopefully a good showcase
Stephen J. Turnbull writes:
> I doubt that __as_parent__ solves the "arbitrarily deep"
problem (although you may be able to persuade me it will work
"better" "most of the time").
The way i've implemented it rn, it is possible :
__as_parent__ can take for argument any class in the inheritance tre
Stephen J. Turnbull writes:
> Shouldn't A and B derive from Parenting? Or is it C that should?
Having Parenting anywhere in the inheritance tree would work with the current
implementation i have for it.
I intended it to be a root parent of any class without pre existing parent.
--
> How does
I've already implemented it here, it's a "simple" recursion (no recursion is
ever simple xD):
https://github.com/malmiteria/super-alternative-to-super/blob/59ff90029db6e4b63fb72bd807e694e9de9514e8/parent.py#L43
Essentially, as long as parent don't have it, you keep
Chris Angelico writes:
> I'm not sure what you DO expect, though.
in this case :
```
class A:
def method(self): pass
class B:
def method(self): pass
class C(A,B): pass
```
it is unclear what C().method should resolve to. So instead of forcing a
resolution, i'd prefer an error to be raised
explicit
where it was unclear. This is probably gonna be a very lenghty post, and i
apologise for that in advance. I started a draft here if you are curious :
https://github.com/malmiteria/super-alternative-to-super/blob/master/conversation/README.md.
When ready, i'll copy paste it he
;m copy pasting it down below, but it is also accessible here :
https://github.com/malmiteria/super-alternative-to-super/tree/master/conversation
A quick TLDR:
there's 5 proposal, i've tried to make them independant of one another, but
they would have to come in order (as far as i can te
Chris Angelico writes:
> And is it still based on the fundamental
> assumption that super() calls THE parent class?
what are you even talking about?
> I don't have the time to read
> that long a post.
Then just read the list of 4-5 features i describe as features of current MRO +
super, at the to
Paul Moor writes :
> PS Please don't respond to this with another wall of text. I won't
> read it.
I'll try my best, just tell me if this is too long.
> your fundamental
> misconception that there is always a single well defined "parent
> class"
I don't hold such a conception
> In practice ther
Chris Angelo writes :
> You start out with the assumption that MOST PEOPLE think of super as a
> way to call THE, singular, parent. If this is indeed a problem, then
> it's not a problem with super, it's a problem with expectations.
This is not so much a problem as this is the context we're working
Chris Angelico writes:
> It's a very real problem in C++, because C++ has a completely
> different concept of multiple inheritance.
Then what's the solution to the diamond problem in python?
in this example :
```
class HighGobelin:
def scream(self):
print("raAaaaAar")
class Corrupted
Steven D'Aprano writes:
> I think that where malmiteria gets it wrong is that he thinks that super
> is broken
I do not, i think its design could be improved overall, but i don't think it's
broken. At best I'd argue it can't be used in all of the use case you'
Greg Ewing writes:
> 1. You hate the existing MRO and super() mechanism with a passion
> and want to rip it out.
I don't hate it, I believe it makes for the most misunderstood python feature
for a reason, and i'm trying to adress it.
> 2. People have objected that this would remove useful funcio
Steven D'Aprano writes:
> > feature 1 (of super alone): proxying the parent.
> > What most people think super does (and expect it to do):
> > it allows to call method from *the* (most people don't think of
> > multiple inheritance) parent.
> For single inheritance, that is exactly what it does, an
nd is something i respect.
This is something i believe you, Chris Angelico, are not capable of.
Chris Angelico writes:
> malmiteria writes:
> > super(A, self) does not proxy to A, but to the first *after* A in MRO order.
> When you call super(A, self), you are expecting to call A's metho
Paul Moore writes:
> > super(A, self) does not proxy to A, but to the first *after* A in MRO order.
> Correct, that's how it's defined to work.
Glad we're on the same page so far.
I love you profile pic by the way
> That's the point - the type
> argument to super() can be omitted in 99% of cases
Chris Angelico writes:
> If you meant it only for me, you could have sent it privately.
Well.. yeah, i probably sould have.
I apologise for that.
> But since you are clearly not returning the favour, I am now done.
> Good luck with your proposal, maybe you can team up with jmf and make
> a new ver
Paul Moore writes:
> this is the first time you've explicitly stated this
this was more explicitely stated earlier in the thread yeah, I honestly can't
blame you for not reading it all.
I'll eventually try to give a quick state of today's proposal to keep it up to
date. I won't have time for th
ROUND 3 i guess
I promised paul moore an up to date proposal, here it is:
1) an alterhitance module, dedicated to all __bases__ (the iterable of parents)
alteration operations
This replaces the "dependency injection" use case (based on MRO injection, not
__bases__ edits), and on its own doesn't
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
Paul Moore writes:
> I
> personally think this is probably useless, but it's not a Python
> change so do it if you want.
I agree, this is most likely useless. Other people on this thread were worried
about dependency injection through MRO injection being lost by my proposal,
today's __bases__ a
Steven D'Aprano writes:
> > All we have today is the screwhammer, and in cases the screw part
> > don't work, you're telling me to get rid of it all. hammer part
> > included.
> That's not how I see it.
> I see that we have a screwdriver (inheritence, including multiple
> inheritence) which is
Greg Ewing writes:
> If I were teaching a newcomer about super, I wouldn't even tell them
> that it *has* a class argument. So they wouldn't have any expectation
> about targeting, because they wouldn't know about it.
I would probably teach newcomers the argumentless form only too. That's all
the
isn't very subtle, as we could want some attribute of each parent to be
dominant, while others to be recessive.
My "can't assume one parent is more specialised" (can be found here :
https://github.com/malmiteria/super-alternative-to-super/blob/master/conversation/README.
Antoine Rozo writes:
> If the only feature you need from super is the proxy one, why don't you
> code your own parent-proxy-type?
I did :
https://github.com/malmiteria/super-alternative-to-super/blob/master/parent.py
This is irrelevant to the discussion we're having i think.
.
Joao S. O. Bueno writes:
> Otherwise, just admit these are some features you thought of yourself
I did.
> not even you seem
> to be quite sure of which should be the specs or deterministic outcome (if
> any)
mathematically deterministic, or "humanly" deterministic? (me
want it to and not other times.
Simple. I never want it to jump sideways.
> You'll have to provide a
> detailed example, not just vague waffling about mixins and
> proxying.
Okay, but waffles are good tho.
again, read it :
https://github.com/malmiteria/super-alternative-to-super/tre
Matsuoka Takuo writes:
> For your particular case of a diamond, the solution below seems
> simpler to me than yours. What problems may it create which your
> solution won't? Or you might refine the problem. It's not easy to
> see the real value of your suggestions.
>
> ```
> class HighGobelin:
David Mertz, Ph.D. writes:
> Malmiteria is the FIRST person I've met "confused" by super().
No need to capitalise the first letter in malmiteria.
I'm not sure what the quotes surrounding confused mean. What do you mean by
those?
> I guess the main threshold to try to
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
Steven D'Aprano writes:
> Yes well that was just silly. Of course the order matters.
The order of inheritance as in, one class inherits from another do matter,
quite obviously, since it's not a symetrical operation, and accordingly, the
syntax is not symettrical.
The order in which parents are pl
David Mertz, Ph.D. writes:
> Are you likewise "confused" by the fact that `a = b - c` is generally
> different from `a = c - b`?!
Why do you always quote confused?
I'm not, but that's because i've been taught / i've experienced that since
primary school. I have been taught math, but not python,
David Mertz, Ph.D. writes:
> Can you think of ANY context in Python in which the order of items in
> parentheses isn't important?!
kwargs
> You are arguing that defining inheritance order is "intuitively" the one
> and only context in which the order of items in parentheses makes no
> difference.
Steven D'Aprano writes:
> In any case, how do you know what "most people" think? Have you done a
> survey, or are you just guessing?
I haven't done a survey, but I'm getting one ready, I also wanna let you all
have a read at it before running it, so we can all agree the data we would get
from it
Steven D'Aprano writes:
> So in the general case, order matters. We have to linearize the
> superclasses, and call them in that linear order, and the best way to do
> that is with the MRO and super.
Why would we *have* to do that?
When multiple parent provide candidate to a method resolution, ra
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 sc
Steven D'Aprano writes:
> Do you think that the order of arguments in func(a, b) doesn't matter?
Actually it doesn't:
```
def func(a, b):
print(a)
print(b)
func(b=10, a=5)
```
would print 5, then 10
But i get what you mean, and i know very much it matters here.
> One of the reasons why t
Ronald Oussoren writes:
> To be blunt: That’s not going to happen because this is big backward
> compatibility break. Either that, or this adds a
> second way to define classes. Both are good reasons to keep the status quo.
the breaking is limited MI with name collision, so likely rare enough,
in, CorruptedGobelin):
def scream(self):
if random.choice([True, False]):
super(ProudGobelin, self).scream()
# OR : super(ProudGobelin).scream()
# OR : self.__as_parent__(ProudGobelin).scream(), in the toy
implementation i made here :
https://g
Eric V. Smith writes:
> I've said this before, but I'll repeat it here: if your proposal is to
> have super().something raise an error if "something" exists on more than
> one parent class (via the MRO), then that's a breaking change and it
> will not be accepted.
The expliciteness required erro
Chris Angelico writes:
> A proposal that breaks existing code, and which introduces a new way
> to do things, will usually require multiple versions of deprecation
> time in order to be accepted.
Nothing is preventing us from doing that here.
I already intend to have the adoption syntax come first,
o languages that do something very
> similar to what malmalitia is proposing
malmiteria xD not malmalitia
---
David Mertz, Ph.D. writes:
> I also co-authored a widely read article on then-new C3 linearization in
> Python with Michele Simianato before he wrote his really great explanati
Greg Ewing writes:
> > malmiteria xD not malmalitia
> Sorry! Should have gone to Specsavers...
No worries :)
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.p
Chris Angelico writes:
> I'm with Greg on this one, for the simple reason that a future
> language could have fewer restrictions than Python does, and therefore
> would become the only thing that offers "full MI", displacing other
> languages. It's a meaningless concept, unless there is some form o
I'm a bit late to this conversation, but here i go:
Steven d'Aprano writes:
> But given the assumptions that:
>
> - the inheritance model automatically resolves conflicts;
>
> - the MRO is entirely dependendent on the shape of the inheritance
> graph, and not on incidental properties like the
Stephen J. Turnbull writes
> Every feature means making an arbitrary choice that may or may not be
> what the programmers wanted.
I don't think that's what greg meant.
It's not an arbitrary choice between multiple possible features that would
cover the same need.
It's an arbitrary choice that the
Greg Ewing writes:
> Even if you do, it's still an arbitrary choice to prefer the leftmost
> method, which might be what you want or might not.
Yep, i 100% agree with you, and that's (one of) my problems with current MI in
python, and the reason i named that thread MRO and super don't feel so pyt
Stephen J. Turnbull writes:
> PermissionsMixin is documented to be *abstract* -- there are *no*
> default permissions in it. It either does nothing or errors when you
> try to use the methods it declares.[1]
>
> The permission-checking is (and must be) your code. For one thing,
> that's what "ab
Steven D'Aprano writes:
> It just means that Python
> handles more cases than Eiffel or C++
Does C++ or Eiffel ban some class inheritance tree like python does?
I can't find sources on that, although, i didn't spend an hour looking for it.
But if not, i would say that python handle less cases than
60 matches
Mail list logo
