[Python-Dev] Computed Goto dispatch for Python 2

[Donald Stufft]

On May 28, 2015 at 10:10:03 AM, Nick Coghlan (ncoghlan at gmail.com) wrote:
> On 28 May 2015 at 21:55, Maciej Fijalkowski 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
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io  
>  


I think docker is a pretty crummy answer to Go’s static binaries. What I would
love is for Python to get:

* The ability to import .so modules via zipzimport (ideally without a temporary
  directory, but that might require newer APIs from libc and such).
* The ability to create a “static” Python that links everything it needs into
  the binary to do a zipimport of everything else (including the stdlib).
* The ability to execute a zipfile that has been concat onto the end of the
  Python binary.

I think that if we get all of that, we could easily create a single file executable
with real, native support from Python by simply compiling Python in that static
mode and then appending a zip file containing the standard library and any other
distributions we need to the end of it.

We’d probably want some more quality of life improvements around accessing resources
from within that zip file as well, but that can be done as a library easier than
the above three things can.

---  
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA