Hacker News new | ask | show | jobs
by alephnil 3644 days ago
The argument is that Python spend most time in the C runtime, but that is really only a property of the current implementation. If I use Jython or even implement Python on top of bare metal, making Python the OS, that will not be spending any time in the C runtime because there wouldn't be one, but that's besides the point.

The question is whether an implementation could be made significantly faster than the current Python interpreter is, or whether there are properties of the Python semantics that makes that hard. One such thing is the amount of dynamic behavior that is allowed in Python. That require most variables to be boxed, even for basic types like numbers. There are dynamic languages (LuaJIT was mentioned, but Javascript, Julia and several Lisp implementation could be mentioned as well) that are considerably faster than Python, so why isn't Python fast?

Personally I think that Python could be made quite a bit faster than it is, but such a new Python system would almost certainly be incompatible with a large number of the Python libraries that interface with native code. For most Python users, this availability of libraries is a major motivation for using Python in the first place, and a new fast implementation without such compatibility would be worthless for most users.