> Can you seriously say it's easier to write hard to read python than writing hard to read Rust or C++ ?

Dynamic typing and passing around *kwargs make this so trivial often the documentation doesn't even help and your IDE can't help you without executing the entire program.

There are certainly some things about Python that make it easier to write hard-to-read code in it compared to Rust.

One example is that booleans in Python are considered integers (0 and 1) for all purposes, including arithmetic: True+True produces 2 with no warning whatsoever. Even in C++, where this is also legal, you usually also get a warning.

And conversely, Python is much more flexible when it comes to interpreting other things as booleans: on top of implicitly treating null pointers and integers as false like C does, Python does the same to empty strings and even collections. Then there's the part where "and" and "or" don't just return true/false, but rather the value of one of the operands, which needs not be a boolean.

Sequence comprehensions are also a mighty tool for producing unreadable code if desired, especially if you nest them and/or use the conditional operator. This is more so in Python due to the unusually ordered syntax for both.

Here's a fizzbuzz code golf example that combines these techniques:

   [f"{(not x % 3) * 'Fizz'}{(not x % 5) * 'Buzz'}" or x for x in range(1, 20)]

Decorator over-use can lead to some difficult-to-read Python.

Doing just about anything imperative at import-time makes it hard to reason about what happens when. Even experienced Python programmers can get tripped up by the import system's order of evaluation.