On Thu, 29 Nov 2018 at 18:09, Steve Dower
On 29Nov2018 0923, Antoine Pitrou wrote:
I think the whole argument amounts to hand waving anyway. You are inventing an extended distribution which doesn't exist (except as Anaconda) to justify that we shouldn't accept more modules in the stdlib. But obviously maintaining an extended distribution is a lot more work than accepting a single module in the stdlib, and that's why you don't see anyone doing it, even though people have been floating the idea for years.
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
Do I need to keep going?
Nope, you've already demonstrated the problem with recommending external distributions :-) Which one do I promote within my company? Suppose I say "the Linux distro packaged version", Then Windows clients are out of the picture. If I say "Anaconda" for them, they will use (for example) numpy, and the resulting scripts won't work on the Linux machines. Choice is not always an advantage. Every single one of those distributions includes the stdlib. If we remove the stdlib, what will end up as the lowest common denominator functionality that all Python scripts can assume? Obviously at least initially, inertia will mean the stdlib will still be present, but how long will it be before someone removes urllib in favour of the (better, but with an incompatible API) requests library? And how then can a "generic" Python script get a resource from the web?
Accepting a module in the stdlib means accepting the full development and maintenance burden.
Absolutely. And yes, that's a significant cost that we pay.
Maintaining a list of "we recommend these so strongly here's an installer that will give them to you" is a very different kind of burden, and one that is significantly easier to bear.
OK, so that reduces our costs. But what about our users? Does it increase their costs, offer a benefit to them, or is it cost-neutral? Obviously it depends on the user, but I contend that overall, it's a cost for our user base (even users who have easy access to PyPI will still incur overheads for an extra external dependency). So we're asking our users to pay the cost for a benefit to us. That may be reasonable, but let's at least be clear about it. Alternatively, if you *do* see it as a benefit for our users, I'd like to know how, because I'm missing that point. Paul