Hacker News Reader

Comment by mehrdadn | Hacker News Reader

> 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.

Er, what syntax error are you talking about? https://ideone.com/3hI4Wj

View on HN

> 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.

Example: https://repl.it/repls/BumpyPreemptiveQuerylanguage

> Isn't this a bug in class C, not your original snippet?

It's not. The bug is in A.__init__. It needs to call super().__init__(). C would work fine in that case.

I take it that your claim is that every class should always call super().__init__(), or else it's a bug? What makes you think so?

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.

> every class should always call super().__init__()

For this to work, should every class also have an __init__ method that accepts zero arguments?

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.

> C would work fine in that case

C also works fine in the case where you understand how multiple inheritance works in Python and structure your classes accordingly though...

I.e. inherit B first instead of A like I showed.

You're still arguing in bad faith. Your original code snippet didn't mention any kind of inheritance at all.

Reply on news.ycombinator.com