Re: 'programming styles from different languages are (to a varying extent) supported'
things it doesn't do (I've probably missed some):
- compile time checks - there are some basic syntax checks (dangling commas, bad indents, etc...), but nothing like a real compiler. It is an interpreted language, albeit a strongly typed one. Even the 3.x type annotations are more intended for 3rd party library parsing than real compile time type checking. That's a hard separation - you either want compile checks or you don't.
- information hiding and encapsulation. There is no privacy as such to class and module attributes, though single underscore, _my_somewhat_private, by convention means non-public and double underscores, __my_almost_private, are obfuscated, but still accessible.
- full-on threading. There's something called the Global Interpreter Lock in the main (C-based) version of the language that enforces code locks. It looks like full threading from the POV of the coder, but code blocks will take their turn in some cases. Different ways exist to mitigate, and it looks fine from the dev's POV, but it's still there.
- speed. You can find cases of quick Python programs that compare fairly favorably to C alternatives, but that's just because the algos are not CPU-bound. Or they are, but the heavy lifting could be left to objects which are implemented in C. For example, the built-in hash maps are very clever and can often make a huge difference in speed, but they're C-based, not native Python. Ditto things like pandas or numpy, used in data science - libs are all in C, but dev need not care. Generally, Python knows full well that it can't do everything quickly and goes out of its way to facilitate interfacing to native compiled code.
Pure Python CPU-bound code? Slow. Writing a driver in Python? Not a great idea.
- it's not manual memory management. Which means you may experience the joys of garbage collection kicking in at inopportune moments.