On Sep 2, 2014, at 4:01 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:


On 3 Sep 2014 08:18, "Alex Gaynor" <alex.gaynor@gmail.com> wrote:
>
> Antoine Pitrou <solipsis <at> pitrou.net> writes:
>
> >
> > And how many people are using Twisted as an HTTPS client?
> > (compared to e.g. Python's httplib, and all the third-party libraries
> > building on it?)
> >
>
> I don't think anyone could give an honest estimate of these counts, however
> there's two factors to bare in mind: a) It's extremely strongly recommended to
> use requests to make any HTTP requests precisely because httplib is negligent
> in certificate and hostname checking by default, b) We're talking about
> Python3, which has fewer users than Python2.

Creating *new* incompatibilities between Python 2 & Python 3 is a major point of concern. One key focus of 3.5 is *reducing* barriers to migration, and this PEP would be raising a new one.

No.  Providing the security that the user originally asked for is not a "backwards incompatible change".  It is a bug fix.  And believe me: I care a _LOT_ about reducing barriers to migration.  This would not be on my list of the top 1000 things that make migration difficult.

It's a change worth making, but we have time to ensure there are easy ways to do things like skipping cert validation, or tolerate expired certificates.

The API already supports both of these things.  What I believe you're implicitly saying is that there needs to be a way to do this without editing code, and... no, there really doesn't.  Not to mention the fact that you could already craft a horrific monkeypatch to allow operators to cause the ssl module to malfunction by 'pip install'ing a separate package, which is about as supported as this should be.

-glyph