[Python-Dev] Computed Goto dispatch for Python 2 (original) (raw)
Donald Stufft donald at stufft.io
Thu May 28 16:37:24 CEST 2015
- Previous message (by thread): [Python-Dev] Computed Goto dispatch for Python 2
- Next message (by thread): [Python-Dev] Computed Goto dispatch for Python 2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] Computed Goto dispatch for Python 2
- Next message (by thread): [Python-Dev] Computed Goto dispatch for Python 2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]