[Python-Dev] Proposed schedule for 3.4.2

[Glenn Linderman]

Well, this thread seems to be top-posted.... so...

Why not provide _urlopen_with_scary_keyword_parameter as the 
monkey-patch option?

So after the (global to the module) monkeypatch, they would _still_ have 
to add the keyword parameter.


On 9/8/2014 4:31 PM, Guido van Rossum wrote:
> 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.
>
> 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.
>
> I'm fine with giving the actual keyword parameter a scary-sounding 
> ugly name.
>
> On Mon, Sep 8, 2014 at 3:48 PM, Donald Stufft <donald at stufft.io 
> <mailto:donald at stufft.io>> wrote:
>
>
>>     On Sep 8, 2014, at 6:43 PM, Nick Coghlan <ncoghlan at gmail.com
>>     <mailto:ncoghlan at gmail.com>> wrote:
>>
>>
>>     On 9 Sep 2014 08:30, "Donald Stufft" <donald at stufft.io
>>     <mailto:donald at stufft.io>> wrote:
>>     >
>>     > If someone wants to do this, can’t they write their own 6 line
>>     function?
>>
>>     Unfortunately not, as the domain knowledge required to know what
>>     those six lines should look like is significant.
>>
>>     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".
>>
>>     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.
>>
>>     Cheers,
>>     Nick.
>>
>>     >
>>     > import ssl
>>     > import urllib.request
>>     > _real_urlopen = urllib.request.urlopen
>>     > def _unverified(*args, **kwargs):
>>     >     if not kwargs.keys() & {“context”, “cafile”, “capath”,
>>     “cadefault”}:
>>     >         ctx = ssl.create_default_context()
>>     >         ctx.verify_mode = CERT_NONE
>>     >         ctx.verify_hostname = False
>>     >         kwargs[“context”] = ctx
>>     >     return _real_urlopen(*args, **kwargs)
>>     >
>>     > ---
>>     > Donald Stufft
>>     > PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>>     >
>>
>
>     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.
>
>     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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140908/d3c24f43/attachment-0001.html>