On 2014-03-25 01:29, Ben Darnell wrote:
On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan <ncogh...@gmail.com
<mailto:ncogh...@gmail.com>> wrote:
On 24 Mar 2014 15:25, "Chris Angelico" <ros...@gmail.com
<mailto:ros...@gmail.com>> wrote:
> As has already been pointed out, this can already happen, but in an
> ad-hoc way. Making it official or semi-official would mean that a
> script written for Debian's "Python 2.7.10" would run on Red Hat's
> "Python 2.7.10", which would surely be an advantage.
And having it break on the official Windows and Mac OS X binaries
would benefit end users, how?
The position I am coming to is that the "enhanced security" release
should be the default one that we publish binary installers for, but
we should also ensure that downstream redistributors can easily do
"Python 2.7 with legacy SSL" releases if they so choose. I'm happier
forcing end users to rely on a redistributor to opt in to a lower
security option than I am to knowingly publish too many additional
releases with network security infrastructure that is (at best)
rapidly approaching its use by date.
I am strongly against allowing downstream distributors that choice.
Unless the security-enhanced variant of Python 2.7 quickly and
completely overtakes all previous versions, we will be creating a
compatibility problem between the two variants of Python 2.7. I believe
that the changes motivating this PEP can be made with minimal
backwards-incompatibility risk and (if the PEP is accepted) we should
use all the leverage at our disposal to drive adoption. The risk is not
backwards incompatibility, it is ambiguity of what Python 2.7 means. If
changes under this PEP would result in any distributors rationally
remaining at Python 2.7.6, then the result of any such changes should be
labelled Python 2.8.
I think that calling it Python 2.8 would be a bad idea for the reasons
that have already been stated.
Perhaps it should just be called Python 2.7 Enhanced Security ("Python
2.7 ES").
_______________________________________________
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
