Python and the need for speed

[Paul Rubin]

Steven D'Aprano <steve at 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.