On Sun, Mar 23, 2014 at 7:03 PM, Barry Warsaw <ba...@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 _______________________________________________ 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
