On 23 March 2014 10:08, Antoine Pitrou <solip...@pitrou.net> wrote: > On Sat, 22 Mar 2014 23:54:37 +0100 > Thomas Wouters <tho...@python.org> wrote: >> >> Or not rely on the standard library for their security. Much as I realize >> it is necessary for rudimentary SSL support (for example) to exist in the >> standard library, > > Unfortunately, "rudimentary SSL support" is worse than nothing.
I'm going to try to find a way to steal that line and get it into the PEP. I'm not sure yet if my proposal is the *right* answer, but this observation gets right to the heart of the problem that actually needs to be solved. I'd actually welcome a competing PEP that seriously explored separating out the relevant parts of the Python 3.4 standard library as a PyPI project and attempted to tackle the problem by making that available at least as far back as 2.7 and then just deprecating the leaking batteries in the 2.7 standard library. Just because I think that approach would be even more work and even more disruptive than what I propose in PEP 466, doesn't mean it isn't a better idea overall. What we have essentially found is that where we could basically get away with an 18 month update cycle for improved network security support (extended out to a few years by certain major platform vendors), that approach *isn't* working when it comes to putting a feature release into long term maintenance mode. I don't think the situation isn't critical yet, but it's getting close, and I think we need to deal with it within the 12 months (and preferably sooner than that). My PEP proposes one way of addressing the challenge: allowing a wider variety of changes in maintenance releases to reduce the variance in capability in this area. Moving the affected modules out of the standard library proper and bundling the critical ones along with pip instead is indeed another alternative. However, that approach introduces additional issues of its own - I'll cover some of them in the next PEP update, but it would be good to have someone explicitly trying to make the case that a PyPI backport would be simpler for the overall ecosystem than my suggested approach. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
