git.net

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

[Python-Dev] Standard library vs Standard distribution?


On Thu, 29 Nov 2018 at 18:09, Steve Dower <steve.dower at python.org> wrote:
>
> 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