git.net

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

[Python-Dev] Standard library vs Standard distribution?


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

Probably an assumption I'm making (because I've argued the case 
previously) is that anything we remove from the current stdlib becomes a 
pip installable package that is preinstalled with the main distro. 
Perhaps our distro doesn't even grow from what it is today - it simply 
gets rearranged a bit on disk.

The benefits for users is now backports are on the same footing as core 
libraries, as are per-package updates.

The "core+precise dependencies" model for deployment could drastically 
improve install times in some circumstances (particularly Windows, but 
hey, that's my area so I care about it :) ).

A number of core packages aren't really tied to the version of Python 
they ship with, and so users could safely backport all fixes and 
improvements at any time.

Longer term, if something happens like "the core only includes a very 
high-level HTTPS API and 'socket' is an extra module if you need that 
API", then we can use the OS APIs and give proper proxy/TLS behaviour in 
core for a narrower set of uses (and sure, maybe the Linux core still 
requires socket and OpenSSL, but other platforms don't have to require 
them for functionality provided by the OS).

Of course, any churn has a risk of causing new issues and so it has a 
cost both to us and users. There will certainly be new shadowing 
concerns, and code changes to unwind tricky dependencies could lead to 
new bugs. I think the upsides are worth it in the long run, but 
obviously that's not (yet) the consensus or we'd be doing it already :)

Cheers,
Steve