On 29 May 2015 2:16 am, "Barry Warsaw" <barry@python.org> wrote:
>
> Go seems to be popular where I work.  It is replacing Python in a number of
> places, although Python (and especially Python 3) is still a very important
> 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 if it
> 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 those
> things you have to recompile the world).
>
> Start up times and memory footprint are also factors.  Probably not much to be
> 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 3.6.)

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 SMoE
> 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 Python
> 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 morph
> as requirements and understanding changes, its batteries included philosophy,
> 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.

Cheers,
Nick.