git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Inclusion of lz4 bindings in stdlib?


On Thu, 29 Nov 2018 at 16:28, Steve Dower <steve.dower at python.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".[1]
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".

Paul