[Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
Nick Coghlan
ncoghlan at gmail.com
Sat Mar 19 01:32:04 CET 2011
More information about the Python-Dev mailing list
Sat Mar 19 01:32:04 CET 2011
- Previous message: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
- Next message: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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. 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. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
- Next message: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list