5 ms·

That's not at all what Python does. It linearizes the inheritance hierarchy for the purposes of superclass attribute lookup, in an attempt to solve some aspects

That's not at all what Python does. It linearizes the inheritance hierarchy for the purposes of superclass attribute lookup, in an attempt to solve some aspects of the diamond problem, or at least make them solvable. But it doesn't touch the types themselves, only the MRO used by the super builtin. That's why the super builtin type takes both the "current" class and the object instance itself, which was more visible before the whining of people who didn't understand it grew too loud to be borne by the maintainers and the project introduced the `super()` syntactic sugar. Not that I'm bitter about that or anything. Anyway, your argument seems to be that you should be able to use naively written classes in a multiple inheritance hierarchy. I suppose that's a defensible opinion, but it's also not the case in any language I know of; C++ solves the problem of not calling the "correct" superclass by default by foisting the responsibility of choosing the correct subset onto the derived class author, but doesn't solve the "I called my superclass' method too many times" problem, only the "I have too many (n>1) copies of my superclass' data" problem (the solution to which is also opt-in). Python resolves all three of these, but in so doing requires careful construction of multiple inheritance hierarchies and use of the super builtin that is religious to the point of fanatical. That's a tradeoff made in respect to a feature that, IMO, is inherently sharp. Aside: "idiosyncratic" is an interesting word to use given that the C3 MRO was originally intended for Dylan.

mehrdadn 6y ago
> That's not at all what Python does. I know what's going on and my comment was sufficiently accurate to get the point across in 1 sentence. I wasn't exactly intending to get into a lecture on MRO here. > C++ solves the problem of not calling the "correct" superclass by default by foisting the responsibility of choosing the correct subset onto the derived class author Which is much better than leaving a ticking time bomb. > doesn't solve the "I called my superclass' method too many times" Er, yes it does. Every class instance in a hierarchy is initialized exactly once. Trying to call it twice will produce an error (e.g. "class has already been initialized"). > Python resolves all three of these It does not. It's perfectly fine letting you call a class's __init__ multiple times. Unlike with C++. > Aside: "idiosyncratic" is an interesting word to use given that the C3 MRO was originally intended for Dylan. It is a fine word. "Idiosyncrasy" does not imply there exists only 1 person in the whole world engaging in the given practice: "Her habit of using “like” in every sentence was just one of her idiosyncrasies." https://www.merriam-webster.com/dictionary/idiosyncrasy https://www.merriam-webster.com/dictionary/idiosyncrasy I'm tired of the pointless arguing so this will be my last comment.
- theg5prank 6y ago
  > I know what's going on and my comment was sufficiently accurate to get the point across in 1 sentence. I wasn't exactly intending to get into a lecture on MRO here. I was trying to not assume you were lying through your teeth about what Python method lookup is like in order to conflate fact and your personal opinion. Happy to be corrected. > Which is much better than leaving a ticking time bomb. It's a different implementation choice. That it is better is a perfectly valid opinion. Though, if A doesn't already know it's part of a multiple inheritance hierarchy it's not possible to know what __init__'s signature should be. I'm sure you're eliding that for a good reason, though. > Er, yes it does. Every class instance in a hierarchy is initialized exactly once. Trying to call it twice will produce an error (e.g. "class has already been initialized"). This is true only for constructors, not arbitrary methods; __init__ in Python is much more arguably an ordinary method. I'm going to assume you're always using virtual inheritance, an opt-in feature, because otherwise you are being misleading and disingenuous in more ways. > It does not. It's perfectly fine letting you call a class's __init__ multiple times. Unlike with C++. True only for constructors in C++, and if you don't use super() in Python. Python treats __init__ and other methods fairly uniformly here. >It is a fine word. "Idiosyncrasy" does not imply there exists only 1 person in the whole world engaging in the given practice: >"Her habit of using “like” in every sentence was just one of her idiosyncrasies." >https://www.merriam-webster.com/dictionary/idiosyncrasy https://www.merriam-webster.com/dictionary/idiosyncrasy Sure, go off, but my point is that other languages you have heard of do the same thing. It's not some dumb thing Python is doing for no reason as you were implying.

mehrdadn 6y ago

> That's not at all what Python does. I know what's going on and my comment was sufficiently accurate to get the point across in 1 sentence. I wasn't exactly intending to get into a lecture on MRO here. > C++ solves the problem of not calling the "correct" superclass by default by foisting the responsibility of choosing the correct subset onto the derived class author Which is much better than leaving a ticking time bomb. > doesn't solve the "I called my superclass' method too many times" Er, yes it does. Every class instance in a hierarchy is initialized exactly once. Trying to call it twice will produce an error (e.g. "class has already been initialized"). > Python resolves all three of these It does not. It's perfectly fine letting you call a class's __init__ multiple times. Unlike with C++. > Aside: "idiosyncratic" is an interesting word to use given that the C3 MRO was originally intended for Dylan. It is a fine word. "Idiosyncrasy" does not imply there exists only 1 person in the whole world engaging in the given practice: "Her habit of using “like” in every sentence was just one of her idiosyncrasies." https://www.merriam-webster.com/dictionary/idiosyncrasy https://www.merriam-webster.com/dictionary/idiosyncrasy I'm tired of the pointless arguing so this will be my last comment.

theg5prank 6y ago
> I know what's going on and my comment was sufficiently accurate to get the point across in 1 sentence. I wasn't exactly intending to get into a lecture on MRO here. I was trying to not assume you were lying through your teeth about what Python method lookup is like in order to conflate fact and your personal opinion. Happy to be corrected. > Which is much better than leaving a ticking time bomb. It's a different implementation choice. That it is better is a perfectly valid opinion. Though, if A doesn't already know it's part of a multiple inheritance hierarchy it's not possible to know what __init__'s signature should be. I'm sure you're eliding that for a good reason, though. > Er, yes it does. Every class instance in a hierarchy is initialized exactly once. Trying to call it twice will produce an error (e.g. "class has already been initialized"). This is true only for constructors, not arbitrary methods; __init__ in Python is much more arguably an ordinary method. I'm going to assume you're always using virtual inheritance, an opt-in feature, because otherwise you are being misleading and disingenuous in more ways. > It does not. It's perfectly fine letting you call a class's __init__ multiple times. Unlike with C++. True only for constructors in C++, and if you don't use super() in Python. Python treats __init__ and other methods fairly uniformly here. >It is a fine word. "Idiosyncrasy" does not imply there exists only 1 person in the whole world engaging in the given practice: >"Her habit of using “like” in every sentence was just one of her idiosyncrasies." >https://www.merriam-webster.com/dictionary/idiosyncrasy https://www.merriam-webster.com/dictionary/idiosyncrasy Sure, go off, but my point is that other languages you have heard of do the same thing. It's not some dumb thing Python is doing for no reason as you were implying.