<div dir="ltr"><div><div>Replacing urllib.urlopen(url) with urllib._unsafe_urlopen_without_secure_https(url) would be fine too (actual name to be picked by whoever writes the code) but I don't see that it offers much more of a barrier against abuse of this compatibility feature compared to a keyword argument.<br><br>Requiring a monkeypatch feels unnecessarily mean -- I see no reason why the code can't be in the standard library. It's a bit like the emergency hammer on a train -- what keeps riders from misusing it is convention (and the sign next to it), since locking it up would miss the point.<br><br>Do note that there are a couple of different common patterns for how this is used in legacy code, e.g. urllib vs.urllib2, URLOpener vs FancyURLOpener, urlopen vs. urlretrieve; there are also some internal calls, e.g. in response to redirects. The ultimate form of the solution (keyword argument of alternate function or whatever) may depend on the needs of these various (ancient) architectures.<br><br></div>Regarding 3.4 and 3.5, there's presumably much less legacy code for 3.4, but its expected lifetime is also much shorter than 2.7's (since we're already close to releasing 3.5). So I'm still a bit torn -- in the end one reason to do it in 3.4 is that 3.4 shouldn't have a weaker default than 2.7.<br><br></div><div>Onwards,<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 8, 2014 at 7:46 PM, Glenn Linderman <span dir="ltr"><<a href="mailto:v+python@g.nevcal.com" target="_blank">v+python@g.nevcal.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#330033">
<div>Well, this thread seems to be
top-posted.... so...<br>
<br>
Why not provide _urlopen_with_scary_keyword_parameter as the
monkey-patch option?<br>
<br>
So after the (global to the module) monkeypatch, they would
_still_ have to add the keyword parameter.<div><div class="h5"><br>
<br>
<br>
On 9/8/2014 4:31 PM, Guido van Rossum wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">I still prefer having a parameter on urlopen (or
thereabouts) -- it feels wrong to make it easier to change this
globally than on a per-call basis, and if you don't understand
monkey-patching, it's impossible to debug if you put the patch
in the wrong place.<br>
<br>
For the poor soul who has a script with many
urlopen("https"//<whatever>") calls, well, they probably
don't mind the busywork of editing each and every one of them.<br>
<br>
I'm fine with giving the actual keyword parameter a
scary-sounding ugly name.<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Sep 8, 2014 at 3:48 PM, Donald
Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<div><br>
<div>
<blockquote type="cite">
<div>On Sep 8, 2014, at 6:43 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>>
wrote:</div>
<br>
<div>
<p dir="ltr"><br>
On 9 Sep 2014 08:30, "Donald Stufft" <<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>>
wrote:<br>
><br>
> If someone wants to do this, can’t they
write their own 6 line function?</p>
<p dir="ltr">Unfortunately not, as the domain
knowledge required to know what those six
lines should look like is significant.</p>
<p dir="ltr">Keeping the old unsafe behaviour
around with a more obviously dangerous name is
much simpler than explaining to people "Here,
copy this chunk of code you don't understand".</p>
<p dir="ltr">If we were starting with a blank
slate there's no way we'd offer such a thing,
but as Jim pointed out, we do want to make it
relatively easy for Standard Operating
Environment maintainers to hack around it if
necessary.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> import ssl<br>
> import urllib.request<br>
> _real_urlopen = urllib.request.urlopen<br>
> def _unverified(*args, **kwargs):<br>
> if not kwargs.keys() &
{“context”, “cafile”, “capath”, “cadefault”}:<br>
> ctx =
ssl.create_default_context()<br>
> ctx.verify_mode = CERT_NONE<br>
> ctx.verify_hostname = False<br>
> kwargs[“context”] = ctx<br>
> return _real_urlopen(*args, **kwargs)<br>
><br>
> ---<br>
> Donald Stufft<br>
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C
BCE9 3372 DCFA<br>
><br>
</p>
</div>
</blockquote>
</div>
<div><br>
</div>
</div>
</div>
<div>Why isn’t documentation with appropriate red warnings
a suitable place if we really must have it? That sounds
like a much better solution that some weird function
people monkeypatch. It gives them more control over
things (maybe they have a valid certificate chain, but
an invalid host name!), it’ll work across all Python
implementations, and most importantly, it gives us a
place where there is some long form location to be like
“yea you really probably don’t want to be doing this” in
big red letters.</div>
<div><br>
</div>
<div>Overall I’m -1 on either offering the function or
documenting it at all, but if we must do something then
I think documentation is more than enough.<br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div>