This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients alex, barry, bkabrda, doko, dstufft, janssen, ncoghlan, pitrou, r.david.murray, rkuska, vstinner
Date 2015-04-05.11:05:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
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.
Date User Action Args
2015-04-05 11:05:49pitrousetrecipients: + pitrou, barry, doko, ncoghlan, janssen, vstinner, alex, r.david.murray, bkabrda, dstufft, rkuska
2015-04-05 11:05:48pitroulinkissue23857 messages
2015-04-05 11:05:48pitroucreate