Python and the need for speed

[Brecht Machiels]

On 2017-04-11 08:19:31 +0000, Steven D'Aprano said:

> On Sun, 09 Apr 2017 19:05:35 +1000, Chris Angelico wrote:
> 
>> When people talk about making a restricted optimizable subset of Python,
>> the implication (if not the explicit declaration) is that it's done
>> strictly by removing, not by rewriting.
> 
> Maybe *some* people have a naive, if not foolish, idea that all you need
> to do to speed up CPython is to go through the C code and hit delete over
> any functions you don't want. But that's hardly a technique that is going
> to work: not only will you break features, but merely removing code
> doesn't magically make the rest of the code base faster.
> 
> At the very least, you have to re-write the code that depends on the
> features you have just removed.
> 
> 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.

Hey! This random, ignorant blogger has feelings too! :-)
I don't know much about interpreter or compiler design, but I never 
claimed that speeding up CPython would simply be a matter of deleting 
some code. I merely suggested that approaches different from PyPy and 
other JIT compilers should be explored, since I do not feel that these 
projects are delivering satisfactory results. I am glad to see it got 
this discussion started, at the very least.

> some are actively maintained and
> used in production by many people (cython, PyPy).

Are there any statistics on PyPy usage? I'm not convinced it is being 
used widely. As far as I can tell, it really is only useful for server 
applications because of the long JIT warm-up time.

> The Python ecosystem is actually quite healthy, if you need to speed up
> code there are lots of solutions, and some of them are even good
> solutions.

There seem to be no solutions for my use case (rinohtype). DropBox and 
Google seem to agree that there are no good solutions, since they are 
moving to Go.

> Nevertheless, it is interesting to discuss whether or not any
> of these features will go mainstream or make it into CPython.

Indeed! I initially wanted to include the following in the article, but 
decided it would be too controversial. But now that I've been exposed 
as an ignorant and naive blogger, I might as well share these thoughts.

I have the feeling that a faster Python will never materialise unless 
the CPython core developers make performance a high priority. I 
understand that high performance was never a goal in CPython 
development (and Python language design!), but recent events (DropBox, 
Google) might help to reconsider that standpoint.

Here's a wild idea: consider Python 3 feature-complete. Similar to how 
Python 3 cleaned up the unicode and other warts of Python 2, Python 4 
could clean up the performance warts, but retaining the "soul" of the 
language. But that last part is a diffucult one, because it would lead 
to endless discussions of what would still be Python. So it's better to 
define an official "TurboPython" subset. This would also ensure 
backwards compatibility, but of course complicate the implementation.

But who am I (or anyone) to suggest what the CPython core developers 
should do? I can only supply food for thought.

Best regards,
Brecht