On Fri, Mar 18, 2011 at 5:32 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Fri, Mar 18, 2011 at 1:38 PM, Guido van Rossum <gu...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
