[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

[Nick Coghlan]

On 25 March 2014 00:18, Skip Montanaro <skip at pobox.com> wrote:
> On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan <ncoghlan at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia