On 25 March 2014 00:18, Skip Montanaro <s...@pobox.com> wrote: > On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> For example, RHEL7 and derivatives are already locked in to 2.7 until >> 2024, RHEL6 and derivatives are locked in to 2.6 until 2020. The only >> way to keep those combination of RHEL and the Python 2 standard >> library from holding back the evolution of internet security standards >> is to find a way solve the problem *within* the 2.7 line in such a way >> that I can then make the case for also backporting it to 2.6 in a >> RHEL6 point release. > > Thanks for the explanation. I'm still a bit confused though. If there > are backward compatibility issues with the proposed changes (whatever > they turn out to be), are the commercial redistributors still going to > balk at releasing these changes to their customers? From the reading > I've done (this thread and your second iteration of the PEP), it seems > like application developers will have to make some changes to take > advantage of these updated security bits. Is there some path forward > that really makes everything a drop-in improvement, requiring no > change to application code, and breaking nothing that already works?
The PEP does not permit backwards compatibility breaks in maintenance releases, thus people are solely concerned about the increased risk of regressions created by backporting all of the Python 3 enhancements to these modules to Python 2.7 and then ensuring that the default behaviour remains the same as earlier Python 2.7 releases. I think those folks have their priorities back to front, hence http://www.python.org/dev/peps/pep-0466/#handling-lower-security-environments-with-low-risk-tolerance :) 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
