[Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)
ncoghlan at gmail.com
Fri May 29 01:38:49 CEST 2015
On 29 May 2015 2:16 am, "Barry Warsaw" <barry at python.org> wrote:
> Go seems to be popular where I work. It is replacing Python in a number
> places, although Python (and especially Python 3) is still a very
> part of our language toolbox.
> There are several reasons why Go is gaining popularity. Single-file
> executables is definitely a reason; it makes deployment very easy, even
> increases the maintenance burden (e.g. without shared libraries, you have
> multiple copies of things so when a security fix is required for one of
> things you have to recompile the world).
> Start up times and memory footprint are also factors. Probably not much
> done about the latter, but perhaps PEP 432 can lead to improvements in the
> former. (Hey Nick, I'm guessing you'll want to bump that one back to
Yep. I got the feature branch mostly working again just after PyCon (since
several folks expressed interest in helping with it), and thanks to Eric
Snow, the biggest blocker to further progress (splitting the import system
initialisation into two distinct phases) has already been addressed for 3.5
(that's not merged into the feature branch in my sandbox repo yet, though).
PEP 432 itself isn't likely to change startup time for the full interpreter
runtime very much (as it's mostly about rearranging how we call the
existing setup steps, rather than changing the steps themselves), but
having more of the C API available earlier in the bootstrapping cycle will
hopefully lay a foundation for future improvements.
The intent is also to make embedding *much* easier, and have it be trivial
to skip initialising any subsystems that a given application doesn't need.
> Certainly better support for multi-cores comes up a lot. It should be a
> to just get rid of the GIL once and for all <wink>.
Eric's been looking into this as well, and we think there's a plausible
path forward based on changing the way subinterpreters work such that the
GIL can be changed to a read/write lock, and each subinterpreter gets its
own Local Interpreter Lock.
Expect to hear more on that front before too long :)
> One thing I've seen more than once is that new development happens in
> until the problem is understood, then the code is ported to Go. Python's
> short path from idea to working code, along with its ability to quickly
> as requirements and understanding changes, its batteries included
> and its "fits-your-brain" consistency are its biggest strengths!
Right, Go is displacing C/C++ in that regard (moreso than Python itself),
and now that Rust has hit 1.0, I expect we'll see it becoming another
contender for this task. Rust's big advantage over Go in that regard is
being compatible with the C/C++ ecosystem, including Python's cffi.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev