[Python-Dev] Computed Goto dispatch for Python 2

[Nick Coghlan]

On 28 May 2015 at 21:55, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> I'm -1 on the idea because:
>>
>> * Performance improvements are not bug fixes
>> * The patch doesn't make the migration process from Python 2 to Python 3 easier
>
> And this is why people have been porting Python applications to Go.

For folks hitting the kinds of scalability problems that Go is
designed to help with, a few percentage points here and there in
CPython performance aren't going to make a big difference - they'll
need the kinds of speed multipliers that PyPy can offer.

Given that Go can't run Python C extensions any more than PyPy can,
and involves a rewrite in a different programming language to boot,
we'd do well to ponder what Go currently offers that PyPy doesn't. If
we ignore the fashion-driven aspect of "Google wrote it, so it must be
cool" (which we can't do anything about), and if we ignore the
multi-vendor commercial support question (which tends to significantly
lag community adoption for true community driven projects like PyPy),
then one of the big keys in my view is the easy redistributability of
Go binaries.

For Linux based network services (and even Windows these days), Docker
containers offer a potentially compelling way of bundling the PyPy
runtime with Python applications, and Docker, Inc already maintain a
set of PyPy base images at https://registry.hub.docker.com/_/pypy/

Docker's image layering model then means that applications sharing a
PyPy runtime shouldn't need to download the interpreter runtime itself
more than once.

As a result, I personally suspect that better documenting and
promoting the CPython->Docker+PyPy migration option is likely to offer
a more effective alternative to CPython->Go migrations than the more
modest performance improvements we can make to the CPython runtime
itself. (I still think the latter are a good idea, though - there's no
point leaving Python 2.7 slower than it needs to be given the offer of
assistance in maintaining it)

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia