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