RetroSearch Browse

Sat Mar 19 01:41:46 CET 2011 · https://mail.python.org/pipermail/python-dev/2011-March/109491.html

On Fri, Mar 18, 2011 at 5:32 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, Mar 18, 2011 at 1:38 PM, Guido van Rossum <guido at python.org> wrote:
>>> But seriously, I think an additional function or additional flag in the
>>> current functions/method in the parse module is sufficient than going
>>> for another module.
>>
>> I vote for a new function, not a flag. (Others can explain my rule of
>> thumb against flag arguments whose values are nearly always
>> constants.)
>
> When I was last tinkering with this (i.e. when I wrote that proof of
> concept module for a fully RFC 3986 compliant parser), I actually
> replaced the "urljoin" name with "resolve_uriref".
>
> So a minimal change to provide at least RFC 3986 joining semantics
> would be to add a "resolve_uriref" that provides the RFC 3986 join
> semantics, while "urljoin" would continue to follow the older RFCs.

It's a bit long though -- users tend to flock to the shorter name.

> There are additional niceties in RFC 3986 that it would be good to
> provide, but that's when you start to get to the scale of a completely
> new URI parsing module.

Really. Do they still call them URIs? :-)

-- 
--Guido van Rossum (python.org/~guido)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-March/109491.html below:

[Python-Dev] Finally switch urllib.parse to RFC3986 semantics?