On 29/11/2018 17.25, Steve Dower wrote:
On 29Nov2018 0254, Antoine Pitrou wrote:
I'd like to point the discussion is asymmetric here.
On the one hand, people who don't have access to PyPI would _really_ benefit from a larger stdlib with more batteries included.
On the other hand, people who have access to PyPI _don't_ benefit from having a slim stdlib. There's nothing virtuous or advantageous about having _less_ batteries included. Python doesn't become magically faster or more powerful by including less in its standard distribution: the best it does is make the distribution slightly smaller.
So there's really one bunch of people arguing for practical benefits, and another bunch of people arguing for mostly aesthetical or philosophical reasons.
My experience is that the first group would benefit from a larger _standard distribution_, which is not necessarily the same thing as a larger stdlib.
I'm firmly on the "smaller core, larger distribution" side of things, where we as the core team take responsibility for the bare minimum needed to be an effective language and split more functionality out to individual libraries. We then also prepare/recommend a standard distribution that bundles many of these libraries by default (Anaconda style), as well as a minimal one that is a better starting point for low-footprint systems (Miniconda style) or embedding into other apps.
I was about to suggest the same proposal. Thanks, Steve!
The core dev team is already busy to keep Python running and evolving. Pulling more modules into the stdlib has multiple downsides.
An extended Python distribution would solve the issue for users on restricted machines. It's also something that can be handled by a working group instead of a the core dev team. A SIG can do the selection of packages, deal with legal issues, politics and create releases. An extended Python distribution can also be updated outside the release cycle of CPython. This allows out-of-band security updates of libraries that are bundled with an extended distribution.