Steven D'Aprano <st...@pearwood.info> writes: > If we're going to talk about speeding up Python, we ought to talk about > *serious* approaches to the problem, not the musing of random, ignorant > bloggers and other naive commentators. So let's look at what the experts > have done: .... [list snipped]
You might look at MicroPython too (micropython.org). A fairly complete Python 3 implementation with some ahead-of-time compiling, no fancy JIT. Completely breaks the Python C API though. Or you could look at the past 50 years(!) of Lisp and Scheme compilers some of which produce very good code, ask what Python features can't be straightforwardly transliterated into Lisp to use those compilers, then ask whether those features are really important to the average Python user. I don't even think eval is an obstacle. Lots of Lisp systems implement eval by handing expression off to the compiler and then running the compiled code, maybe with a bit of caching like Python and compiled regexps. I remember thinking PyPy made a mistake in trying to preserve all of Python's dynamism, and Python 3 made a mistake in trying to preserve so much compatibility with Python 2 while still breaking minor things. I thought PyPy should have been "TurboPython" that broke lots more Python 2 stuff than Python 3 did, but was as you say maybe 20x faster. Then Python 3 could have been skipped. For a while I thought something like that could become Python 4, but the readout of Python 3 seems to be that its slow uptake came from those minor breaks, so Python 4 won't have even the slightest incompatibility with Python 3 code. I still do my everyday stuff in Python and I'd like to get more conversant with stuff like numpy, but it feels like an old-fashioned language these days. -- https://mail.python.org/mailman/listinfo/python-list