][Thread Next][Date Index
[Python-Dev] Standard library vs Standard distribution?
On Thu, Nov 29, 2018 at 01:30:28PM -0800, Nathaniel Smith wrote:
> > > https://anaconda.com/
> > > https://www.activestate.com/products/activepython/
> > > http://winpython.github.io/
> > > http://python-xy.github.io/
> > > https://www.enthought.com/product/canopy/
> > > https://software.intel.com/en-us/distribution-for-python
> > > http://every-linux-distro-ever.example.com
> Yeah, I draw two conclusions from the list above:
> - Paul expressed uncertainty about how many people are in his position
> of needing a single download with all the batteries included, but
> obviously he's not alone. So many people want a
> single-box-of-batteries that whole businesses are being built on
> fulfilling that need.
I think that's inaccurate: at least some of those are not "box of
batteries" but "nuclear reactor" distros, aimed at adding significant
value to above and beyond anything that the stdlib can practically
include. Things like numpy/scipy, or a powerful IDE.
I'm confident that they're ALL likely to be nuclear reactor distros,
for different values of nuclear reactors, but just in case one of them
is not, I'll say "at least some" *wink*
Another nuclear reactor is packaging itself. Despite pip, installing
third-party packages is still enough of a burden and annoyance that some
people are willing to pay money to have a third-party deal with the
installation hassles. That's a data point going against the "just get it
from PyPI" mindset.
> - Currently, our single-box-of-batteries is doing such a lousy job of
> solving Paul's problem, that people are building whole businesses on
> our failure.
That's an unfairly derogatory way of describing it.
Nobody has suggested that the stdlib could be, or ought to be, the one
solution for *everyone*. That would be impossible. Even Java has a rich
ecosystem of third-party add-ons.
No matter what we have in the stdlib, there's always going to be
opportunities for people to attempt to build businesses on the gaps left
over. And that is how it should be, and we should not conclude that the
stdlib is doing "such a lousy job" at solving problems.
Especially not *Paul's* problems, as I understand he personally is
reasonably satisfied with the stdlib and doesn't use any of those
third-party distros. (Paul, did I get that right?)
We don't know how niche the above distros are. We don't know how
successful their businesses are. All we know is:
(1) they fill at least some gaps in the stdlib;
(2) such gaps are inevitable, no matter how small or large the stdlib
is, it can't be all things to all people;
(3) and this is a sign of a healthy Python ecosystem, not a sign of
failure of the stdlib.
> If Python core wants to be in the business of providing a
> single-box-of-batteries that solves Paul's problem, then we need to
> rethink how the stdlib works.
No we don't "need" to rethink anything. The current model has worked
fine for 25+ years and grew Python from a tiny one-person skunkworks
project in Guido's home to one of the top ten most popular programming
languages in the world, however you measure popularity. And alone(?)
among them, Python is the only one without either an ISO standard or a
major corporate backer pushing it.
We don't absolutely know that Python's success was due to the "batteries
included" policy, but it seems pretty likely. We ought to believe people
when they say that they were drawn to Python because of the stdlib.
There are plenty of other languages that come with a tiny stdlib and
leave everything else to third parties. Outside of those like
browser scripting language (and is backed by an ISO standard and at
least one major companies vigourously driving it), how is that working
out for them?
The current model for the stdlib seems to be working well, and we mess
with it at our peril.