> There should be one– and preferably only one –obvious way to do it.

I'm honestly tired of explaining to people that this line of Python zen does not mean that there shouldn't be more than one ways to do something. On a very literal level, it states that there should be one obvious way to do it -- and in no way defines how many non-obvious ways there should be.

What you're calling "clever" stuff is just regular Python functionalities, even if many of them are non-obvious. The only thing before something being "simple" and "clever" is how much is an individual familiar with something.

Arguably the way to get bitten is _not_ to have that super init call. Seems worth making that a standard practice just to avoid the potential confusion later if the class is ever multiply inherited.

This could be fine, but it does restrict things somewhat and could lead to more unexpected results.

The piece doesn't present the correct way to use multiple inheritance in python, so this section is a bit of a strawman. Namely, it is the responsibility of the inheritor to call init on all subclasses with the arguments it wants to pass on. Maybe the python 3 addition of super() has muddled this responsibility somewhat.

If we use the solution in the piece then we lose the ability to pass non-identity expressions in the arguments we received on to the base classes, and also the ability to have same named arguments but with different values.

If a class wants to pass non-identity expressions, and the underlying base classes use the piece's methodology, then you get a bug.

Nothing in the article is particularly egregious. The only odd one is using Python’s “call your children’s parents” super() for code-reuse and mixins but it’s perfectly normal and pythonic.