Even accepting your argument downthread that the absence of "super().__init__()" here is a bug, this would be a problem that comes from two little magic, not too much! Python requires you to be explicit about this aspect of multiple inheritance, and it sounds to me like you're saying you would rather it be implicit.
No I'm not saying I would rather it be implicit. That can have other adverse repercussions. My goal here was just to identify the problem precisely, because (as you can clearly tell from the thread) it is anything but obvious, even for people who've been using Python for years. I can imagine other ways to mitigate it that don't have dangerous side-effects (like warnings), but there are lots of approaches, and how to solve it is a bit more subjective and warrants a longer discussion.
The pitfall is only part of the problem. The problem is much deeper than that. In Python, the solution lies in the base class, which another author may have written in a totally different time/place. Yet the problem only manifests itself when you, another poor soul, try to derive from it later. This kind of spooky action at a distance pierces abstractions, which is just about the last thing you should want from a programming language... and in a sense it literally violates causality (for the lack of a better word). The poor soul that notices this in multiple-inheritance will have to go very much out of their way to work around it: after spending a while trying to track it down (and understanding what's even going on, which is not easy), they'll have to either monkey-patch the original class at runtime, or introduce superfluous wrappers. That is a very high price to pay, and that's on top of the silent failure that led your code to crash and burn.
But anyway, I was just illustrating Python can be quite complicated (even moreso than C++ in some ways) and has flaws despite its simple and straightforward appearance, and it can catch even experienced developers completely off-guard. Just answering the question you asked, basically.
The original code snippet had no bugs until you added more code, stop arguing in bad faith.
Also, the new snippet has a syntax error, the last version where this was valid reached end of life January 1st, and has been deprecated for 10 years prior to that. Not sure how much stock to put in your python opinions given that context.
> The original code snippet had no bugs until you added more code, stop arguing in bad faith.
Wow, that's a really low blow. I'm arguing in perfectly good faith. Failing to call the base class initializer introduces misbehavior in multiple inheritance and the way this happens in Python is completely unexpected. Not every language is like this.
> Also, the new snippet has a syntax error, the last version where this was valid reached end of life January 1st, and has been deprecated for 10 years prior to that. Not sure how much stock to put in your python opinions given that context.
> Wow, that's a really low blow. I'm arguing in perfectly good faith. Failing to call the base class initializer introduces misbehavior in multiple inheritance and the way this happens in Python is completely unexpected. Not every language is like this
Isn't this a bug in class C, not your original snippet?
I'm also not sure what you mean by "failing to call the base class initializer introduces misbehavior in multiple inheritance", this seems like an issue related to the MRO of the inherited classes.
If you write class C with class B inherited first, the code runs.
The answer is a qualified "yes". Because not only can it no longer participate in multiple inheritance, but it is very prone to misbehaving silently when used in such a manner, even for experienced Python users.
I say qualified because whether or not the bug warrants fixing is another matter. It's more warranted for public-facing APIs than internal code, since it's less practical for downstream users to modify your code. In your internal code, if your team knows about the issue or just avoids multiple inheritance altogether, or if you have some kind of static analysis to check class hierarchies for you, it might be safe to avoid. (Just listing some considerations that I can think of. There might be more.)
My overall point though was just to illustrate one particular example of a flaw that catches even experienced Python developers off-guard, let alone beginners.
That's an excellent question and this opens the door to another another interesting discussion. I don't have the energy for that unfortunately, but to reply to your comment: it's not really important that it succeeds per se. Drastically increasing the likelihood of an error is good enough. What's important is that it mitigates the chances of introducing a bug silently.
There’s no error in the original example; in Python, the ability to participate in inheritance diamonds with arbitrary other classes is a feature which must be explicitly documented and maintained. James Knight wrote a really good piece on this many years ago: https://fuhm.net/super-harmful/
The solution is just to avoid inheritance. It’s full of terrible pitfalls in most languages, but Python more than most.
What's the issue with the original code snippet? This seems to be demonstrating the pitfalls of multiple inheritance which is super clunky in any language.
It's missing a super().__init__() call. This code would've worked fine had that line been there.
You would not encounter this issue in e.g. C++. It's strictly due to Python's idiosyncratic linearization of the inheritance hierarchy, which can make your sibling class (which you have no knowledge of) your superclass. (!!)
"2 calls to Base" is a misleading way to put it. You in fact get exactly 1 call per every instance of Base in the hierarchy (and they act independently). Contrast that with Python where you can accidentally call the same constructor multiple times for the same instance of that class, and Python doesn't care to prevent you. (And notice how others' proposed solutions in another comment did exactly that, and they didn't realize it either.)
> There's virtual base class inheritance but then that's a different problem that's hardly any more straightforward than Python.
This is debatable (the Python behavior is quite unintuitive) but "straightforwardness" is actually besides my point. At least with virtual base classes, the solution (whether complicated or not) is in the same place as the problem: both are in the derived class. With Python, the solution is in the base class, which another author wrote a long time ago. Whereas the problem only occurs when you, another poor soul, tries to derive from it a long time later. This kind of spooky action at a distance makes it impractical to abstract things away... in a sense it literally violates causality (for the lack of a better word)! That's not something to take lightly, to say the least.
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.
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."
No I don't (the code is as-is), but in fact if I did, those those would still suffer from basically the same problem even if I did (exercise for the reader). In modern Python you're supposed to use super().__init__() to let it handle this issue with multiple inheritance.
No no, I understand the problem you're talking about. It is a problem. I'm asking about the solution. Why wouldn't you handle it in the child instead of having siblings be superable?
Essentially, why not do it like this:
class A():
def __init__(self):
self.x = 1
class B():
def __init__(self):
self.y = 2
class C(A, B):
def __init__(self):
A.__init__(self)
B.__init__(self)
print(C().y)
Now your class C can't necessarily be used in a multiple inheritance hierarchy with some other class D, and a class E that inherits from C and D, as C hardcodes what its parents are. Python uses the C3 MRO algorithm to traverse all relevant classes in your hierarchy when you religiously use the super builtin.
But; multiple inheritance is a beast in any language due to its complexity and bringing it up in a discussion of "magic" that python exposes beginners to is specious. It's true that C++ doesn't have this problem, because it has no super keyword and you must explicitly delegate everything, but also introduces the problem that you can have multiple instances of a base class and so has added complexity, virtual inheritance, to solve THAT problem. And tons of languages have a problem where omitting a call to "super" is logically required is not statically diagnosable.
> It's true that C++ doesn't have this problem, because it has no super keyword and you must explicitly delegate everything
It's emphatically not "having a super keyword" or not having it. That's a red herring. Visual C++ has __super and yet it doesn't suffer from this: it errors with "ambiguous call to overloaded function" when there are multiple candidates.
There's a lot more I could say about this (frankly the issue I outlined just scratch the surface of a deeper problem in Python), but this is diverting the discussion. Nobody even said C++ is simple or somehow easier to learn than Python in the first place; I was just pointing out an insidious issue in Python, and frankly, it could've been done better without any need to emulate C++'s approach at all. (Exercise for the reader: suggest improvements.)
> It's emphatically not "having a super keyword" or not having it. That's a red herring. Visual C++ has __super and yet it doesn't suffer from this: it errors with "ambiguous call to overloaded function" when there are multiple candidates
What's your point about this nonstandard extension? My point is that C++ doesn't have the problem of classes not written to be part of a multiple inheritance hierarchy delegating somewhere unexpected because, by design, it doesn't attempt to solve the same problems that Python is. If anything that this nonstandard extension doesn't work in multiple inheritance is agreeing with the points I'm making.
> There's a lot more I could say about this (frankly the issue I outlined just scratch the surface of a deeper problem in Python), but this is diverting the discussion. Nobody even said C++ is simple or somehow easier to learn than Python in the first place; I was just pointing out an insidious issue in Python,
You were the one who brought up C++! (EDIT: this was in a cousin comment.) My point is that different languages navigate this thorny landscape in different ways, but the way in which Python does isn't as haphazard as you are suggesting.
> Exercise for the reader: suggest improvements
Perhaps being part of a multiple inheritance hierarchy is sharp and uncommon enough that it should be opt-in. What are yours?
> What's your point about this nonstandard extension?
My point was what I said: you can have your cake and eat it too. You claimed the issue was due to a lack of a super keyword and I showed you it would not occur even if C++ had super.
> You were the one who brought up C++!
I "brought it up" to illustrate it does one particular thing better than Python. Not to claim it does everything better than Python. If you want a simple, beginner-friendly language, avoid C++ like the plague.
> What are yours?
Idk, for starters maybe produce a warning when multiple inheritance occurs and one of the __init__s in the hierarchy doesn't have an obvious call super().__init__.
> My point was what I said: you can have your cake and eat it too. You claimed the issue was due to a lack of a super keyword and I showed you it would not occur even if C++ had super.
I made no such claim. I said (in my opinion) C++ doesn't have the issue you're raising with Python because it has a completely different design that doesn't attempt to solve diamond problems in superclass attribute lookup. Are we not in agreement?
> I "brought it up" to illustrate it does one particular thing better than Python. Not to claim it does everything better than Python. If you want a simple, beginner-friendly language, avoid C++ like the plague.
You can validly think that C++'s choice here is better. I don't think there's a counterargument to personal preference here. My point was that it does not solve all of the problems Python's super builtin is designed to. And that's fine! It avoids the issue in question! I actually don't understand what you are arguing with here. Personally I think the design goals here are just so wildly different that I don't have a preference, but I admit that's kind of a cop-out.
> Idk, for starters maybe produce a warning when multiple inheritance occurs and one of the __init__s in the hierarchy doesn't call super().__init__.
In general I think having more "warning labels" on multiple inheritance is the right idea, if a language is going to persist in offering it at all. I think this would be a good start, especially for a linter.
That, and: I forgot to mention that not using the super builtin can also lead to unintentionally calling a method twice or more for the same base class in a diamond situation (note that with new-style classes, all multiple inheritance has at least one "diamond" class, often object, but people normally do not delegate to object for obvious reasons; you can imagine a base class Z in this example that A and B inherit from instead, if you wish). So, not using the super builtin can result in both delegating to a superclass' implementation too much, and not at all! This is a problem with multiple inheritance that Python actually solves; virtual inheritance doesn't touch it.
Note that `object` being the root of the class hierarchy implies that you must have careful coordination between all classes in a multiple inheritance hierarchy to determine, for a particular method, when subclasses may/must delegate to super, what the arguments to the method are, and even what the argument names are in some cases! You can't just go glomming classes together and expect it to go well unless you know the classes either don't use the same method names or agree very carefully on what the delgatable interfaces are.
I'm not suggesting it's common; it really depends what the beginner is doing. If you're just learning Python because you're trying to use e.g. a web framework like Django (that uses mixin classes all over the place), then chances are you'll put __init__ somewhere and run into this. If you're doing something else, you might never see this in your life. My comment was just responding directly to the parent comment though (pointing out a Python flaw), not trying to suggest every Python developer will run into this.
