Two decades later, we have a more of a handle on what needs to be dynamic, and what doesn't. Too much dynamism is a headache for both debugging and for the language implementation.
In Python, you can, if you work at it, find a variable in some other process by name, and store into it from another thread. While this is unlikely, you cannot definitively tell at compile time it won't happen. This prevents most compiler optimizations.
You meant "other thread" rather than "other process", right? But that doesn't take much work at all -- just a mutable data structure as a global variable.
"Other thread", yes. The point, though, is that basic optimizations, like hoisting some computation out of a loop, are off the table in Python, because the compiler can't be sure something won't mess with the innards of the loop at run time.
Yes, you can do awful things involving creating an optimized loop, detecting at run time that someone broke it from the outside, and switching from compiled to interpreted mode. I think PyPy does stuff like that. It's a huge effort in the compiler and in the runtime to handle such cases.
It's also part of why Python sucks at threading, with the Global Interpreter Lock. There's not enough separation between threads.
Ruby has a GIL too, as far as I understand. Is the GIL in Ruby comparable to that in Python and present for similar reasons? If so, does that suggest that it's a genuine design constraint rather than a bad design decision? You don't say so explicitly, but your last sentence sounds like it's saying Python's GIL is due to bad design.
In Python, you can, if you work at it, find a variable in some other process by name, and store into it from another thread. While this is unlikely, you cannot definitively tell at compile time it won't happen. This prevents most compiler optimizations.