On Thu, 29 Nov 2018 at 16:28, Steve Dower firstname.lastname@example.org wrote:
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.
For the environments I'm familiar with, a "large standard distribution" would be just as acceptable as a "large standard library". However, we have to be *very* careful that we understand each other if we're going to make a fine distinction like this. So, specifically, my requirements are:
1. The installers shipped from python.org as the "official" Windows builds would need to be the "standard distribution", not a stripped down core. People not familiar with the nuances (colleagues who want to use a Python script I wrote, corporate auditors making decisions on "what's allowed", etc) can't be expected to deal with "Python, but not the one at python.org, this one instead" or even "Python, but make sure you get this non-default download". 2. The various other distributions (Anaconda, ActiveState, ...) would need to buy into, and ship, the "standard distribution" (having to deal with debates around "I have Python", "No you don't, that distribution has different libraries" is problematic for grass-roots adoption - well, for any sort of consistent experience). This is probably both the most difficult requirement to achieve, and the one I'd have the best chance of being somewhat flexible over. But only "somewhat" flexible - we'd rapidly get bogged down in debating questions on a module-by-module basis... 3. The distribution needs to be versioned as a whole. A key point of a "standard set of modules" is not to have to deal with a combinatorial explosion of version management issues. Even "Python x.y.z with library a.b.c" offers some risks, unless the library is pretty stable (slow pace of change is, of course, one of the problems with the stdlib that proponents of a decoupled library hope to solve...)
At this point, I've talked myself into a position where I don't see any practical difference between a stdlib and a standard distribution. So what I think I need is for someone to describe a concrete proposal for a "standard distribution", and explain clearly how it differs from the stdlib, and where it *fails* to meet the above criteria. Then, and only then, can I form a clear view on whether I would be OK with their version of a "standard distribution".