[Python-Dev] Proposed schedule for 3.4.2

[Guido van Rossum]

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.

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.

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.

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.

Onwards,

On Mon, Sep 8, 2014 at 7:46 PM, Glenn Linderman <v+python at g.nevcal.com>
wrote:

>  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> wrote:
>
>>
>>  On Sep 8, 2014, at 6:43 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>
>> On 9 Sep 2014 08:30, "Donald Stufft" <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.
>>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140908/41a15f0a/attachment.html>