On Wed, Mar 16, 2011 at 5:02 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Tue, Mar 15, 2011 at 11:34 PM, Guido van Rossum <gu...@python.org> wrote: >> >> Can you be specific? What is different between those RFCs? > > I finally got around to trying to backport some of the additional > urljoin tests from http://bugs.python.org/issue1500504 (specifically, > the additional ones Mike Brown provided), but got tripped up by the > behavioural changes between the earlier RFCs and RFC 3986 regarding > the way ".." is handled.
Ah, got it. > Even in test_urlparse, a bunch of the normative tests from RFC 3986 > are commented out because they fail (by design) when run through > urllib.parse.urljoin. Some of the additional tests also fail because > our urljoin implementation has a whitelist of schemas that support > relative references, whereas 3986 expects relative references to work > for unknown schemas as well. > > There's actually quite a few more terminology changes as well (as > Senthil pointed out in his email), but it was specifically the failing > test cases for urljoin semantics that bit me again yesterday. > > The problem is that it is quite a lot of work to get fully general URI > parsing to work correctly, but the overlap with legacy URL parsing is > large enough that many (most?) use cases in practice work just fine > with the older RFC semantics. So would having two different API functions, one legacy and one conforming, be a problem? Ideally the conforming API's name would not be something lame like urllib2 but something timeless. :-) -- --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
