<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Sep 2, 2014, at 4:01 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p dir="ltr"><br>
On 3 Sep 2014 08:18, "Alex Gaynor" <<a href="mailto:alex.gaynor@gmail.com">alex.gaynor@gmail.com</a>> wrote:<br>
><br>
> Antoine Pitrou <solipsis <at> <a href="http://pitrou.net/">pitrou.net</a>> writes:<br>
><br>
> ><br>
> > And how many people are using Twisted as an HTTPS client?<br>
> > (compared to e.g. Python's httplib, and all the third-party libraries<br>
> > building on it?)<br>
> ><br>
><br>
> I don't think anyone could give an honest estimate of these counts, however<br>
> there's two factors to bare in mind: a) It's extremely strongly recommended to<br>
> use requests to make any HTTP requests precisely because httplib is negligent<br>
> in certificate and hostname checking by default, b) We're talking about<br>
> Python3, which has fewer users than Python2.</p><p dir="ltr">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.</p></blockquote>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.</div><div><blockquote type="cite"><p dir="ltr">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.</p></blockquote></div><div>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.</div><div><br></div><div>-glyph</div><div><br></div></body></html>