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.