[Python-Dev] Standard library vs Standard distribution?

[Steven D'Aprano]

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 
Javascript, which has a privileged position due to it being the standard 
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.



-- 
Steve