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

[Skip Montanaro]

On Sun, Mar 23, 2014 at 7:03 PM, Barry Warsaw <barry at python.org> wrote:
> I want to stick to our no-Python-2.8 pledge ....

I don't understand this dogmatic adherence to a "no 2.8 pledge." Back
when it was made, I don't think the issue of SSL vulnerabilities was
understood (at least not to the current level). Now we're in a pickle.
We need to find some way to release something that brings the SSL (and
related) feature set up-to-date. In this thread and Nick's PEP have
read about a few ways this might be accomplished (I probably missed a
couple):

* separate the security-dependent bits out into a separate
"semi"-stdlib which would be served from PyPI
* continue with 2.7.x but admit that there will be some possible
backward incompatibilities with earlier 2.7 versions in the affected
modules
* change the name somehow and jump to two-digit micro version numbers

It seems to me the PyPI option should be a non-starter, as it's
unlikely that you will get the bulk of the 2.7 installations to update
to that version, and if people do install it, they wind up with
possible backward incompatibilities. The second option goes against
the drop-in history of micro releases. The third seems just like
"weasel words" to avoid saying "2.8." Also, a careful reading of the
Zen of Python suggests these solutions might violate a number of its
aphorisms (explicit is better than implicit, simple is better than
complex, practicality beats purity).

So what's the big deal? Why can't we be pragmatic and call this thing
(whatever it turns out to be) 2.8? Is this pledge and its rationale
written down in a PEP somewhere, so I can study the reasons behind
what appears at this point to be blind adherence? Did someone
administer a blood oath at a recent PyCon?

Pledge-be-damned-ly y'rs,

Skip