[tyree731]

One of Python’s most serious issues is that it is one of the slowest programming languages actively developed and used today, if it isn’t the slowest outright. This isn’t due to its success, this is due to the language’s performance having been deemed not a priority until somewhat recently.

[Daishiman]

No, this is definitely a key to its success.

A simple C implementation allows everyone and their mother to hack at it and interface with C libraries and add try features and evolve the language through endless PEPs.

Compare Python's language evolution to Java's abysmally slow language evolution because every new feature has to be implemented in a way that works with the JVM's JIT-compatible speed hacks. A _ton_ of very useful things Java could have done simply cannot be done because you can't work against the grain of the JVM. If Python's backward-compatibility is a pain, you have no idea how bad it is in the JVM (see how all the JVM's caveats have hobbled the semantics of generics as a good example).

Not providing the end users any guarantees about performant code means that coders offload the performant areas to libraries that use languages built for performance, keeping that complexity outside of the interpreter and language.

[parhamn]

Genuinely curious, I don't know much about java. But if the JVM is good enough to implement full way-more-performant-than-python languages like scala/kotlin, shouldn't it technically be possible to progress the language without mucking with the JVM internals at all?

[Daishiman]

It’s been tried but dynamic languages are not very well suited to the JVM, but progress has been achieved with things like ‘invokedynamic’. The finer issues have to do with things like numeric representations, C bindings, class loading etc. still there are implementations of Python and Ruby on the JVM but they’re not especiallY popular as you can’t run the big libraries.

[LtWorf]

Yeah, used to be that if it made the interpreter less legible or straightforward it wouldn't get merged.