On Thu, Nov 29, 2018, 08:34 Antoine Pitrou <firstname.lastname@example.org wrote:
Le 29/11/2018 à 17:25, Steve Dower a écrit :
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 may ask ourselves if there is really a large difference between a "standard distribution" and a "standard library". The primary difference seems to be that the distribution is modular, while the stdlib is not.
Some differences that come to mind:
- a standard distribution provides a clear path for creating and managing subsets, which is useful when disk/download weight is an issue. (This is another situation that only affects some people and is easy for most of us to forget about.) I guess this is your "modular" point?
- a standard distribution lets those who *do* have internet access install upgrades incrementally as needed.
- This may be controversial, but my impression is that keeping package development outside the stdlib almost always produces better packages in the long run. You get faster feedback cycles, more responsive maintainers, and it's just easier to find people to help maintain one focused package in an area they care about than it is to get new core devs on board. Of course there's probably some survivorship bias here too (urllib is worse than requests, but is it worse than the average third-party package http client?). But that's my impression.
Concretely: requests, pip, numpy, setuptools are all examples of packages that should *obviously* be included in any self-respecting set of batteries, but where we're not willing to put them in the stdlib. Obviously we aren't doing a great job of supporting offline users, regardless of whether we add lz4.
There are a lot of challenges to switching to a "standard distribution" model. I'm not certain it's the best option. But what I like about it is that it could potentially reduce the conflict between what our different user groups need, instead of playing zero-sum tug-of-war every time this comes up.