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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
