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 the mro
If you want to explicitly delegate a method to a class, you should
explicitly delegate a method to a class.
This is exactly why a lot of folks feel composition is better than
inheritance (at least often so).
You don't need `super()` to call `SomeSpecificClass.method(self, other,
args)`
On Sat, M
TL;DR:
You know you can call the method on any class you want just by
explicitly writting the class name instead os "super()" don't you?
That said, the current MRO (and super) behavior is what folks arrived at
almost 20 years ago, the "C3 algorithm", in Python 2.3 after a little tweak
from the beh
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
On Sat, Mar 26, 2022 at 10:24 AM malmiteria wrote:
> i mean yeah, of course you don't need super.
> And i also understand that feeling that composition is better than
> inheritance.
>
That's a bit beside the point -- we can use inheritance, and also be more
explicit about calling superclass meth
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(
On 2022-03-26 11:15, malmiteria wrote:
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:
d
On 3/26/22 09:57, malmiteria wrote:
> 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 the mro are too implicit, and are silencing what really should be errors.
When I first started usin
On 3/26/22 12:04, Ethan Furman wrote:
> On 3/26/22 09:57, malmiteria wrote:
>
>> 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 the mro are
too implicit, and
>> are silencing what rea
Agreed w/r/t the issue of typing, glad I wasn't the only one who was feeling
that way.
Maybe a reasonable approach would be to potentially add this as an option to
the collections module? Either as an isolated function (`anamedtuple` perhaps)
or add control flow to `namedtuple` such that when o
On Sat, Mar 26, 2022 at 10:50 AM malmiteria wrote:
> why does it have to be automatic?
>
because that's the entire point of super() -- if you don't want automatic,
do what you want by making direct method calls.
> if they think one is more specialized than the other, they make one
> inherit fr
> If I wanted to submit this as a pep (or even just submit this for a
> potential sponsorship), is the best way to go about it to work directly in
> a clone of the c/python repo, or to write a standalone library first and
> then after preliminary approval, add it to c/python?
You don’t need an im
On Sat, Mar 26, 2022 at 10:40:45AM -0700, Christopher Barker wrote:
> Almost -- I think super() acts a proxy to the *perents*, plural.
Correct. In general, classes do not have a parent. They have one or more
parents, each of which in turn can have one or more parents.
Anyone talking about the "
On Sat, Mar 26, 2022 at 05:49:41PM -, malmiteria wrote:
> Also, Eventual hierarchy where the rule won't fit are simply not
> allowed today, no matter your use of super.
> take this one for example :
> ```
> class A(X, Y): pass
> class B(Y, X): pass
> class C(A, B): pass
> ```
Because that i
On Sat, Mar 26, 2022 at 06:15:57PM -, malmiteria wrote:
> class C(A, B):
> pass
> ```
>
> Today, a code such as ```C().method()``` works without any problems
Actually, no, it does not. Only the A.method() runs, because A was not
designed for multiple-inheritance. C inherits from both A
On Sat, Mar 26, 2022 at 11:16 AM malmiteria wrote:
> the alternative to super really is not the important part of my proposal,
> it's the alternative to MRO.
>
wait, what?
We may need some more clarity as to what you are after. You need SOME
method resolution order, and Python's MRO is pretty s
17 matches
Mail list logo
