Antoine Pitrou added the comment: Le 05/04/2015 12:25, Nick Coghlan a écrit : > > This does mean spending more time upfront coming up with a way of > designing the feature that the core development community considers to > be useful independently of backporting considerations (e.g. bringing the > STARTTLS migration into the framework could be useful, as the sad state > of email server certificate validity means that even upstream CPython is > going to need to leave that off by default for the time being).
I'm curious about statistics about e-mail servers, even though unrelated to this issue. > Splitting the two activities (Python upgrade, service network > security > upgrade) this way is potentially desirable even if you have control of > all of the affected Python applications, but it may be absolutely > essential if you're running a proprietary bytecode-only Python > application in the system Python, or simply aren't authorised to make > application level changes to an affected service. True, but this is a repeat of the PEP 476 discussion. Something has changed in the meantime: PEP 476 was accepted and its code has shipped in an official release. There hasn't been any major (or even minor) outcry. Speaking as someone who opposed PEP 476, I now support us moving forward instead of trying to eschew the PEP's deliberate effects. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23857> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
