[Python-Dev] Path object design (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Mon Nov 6 00:06:07 CET 2006

Andrew Dalke schrieb:

urlparse.urljoin("http://blah.com/", "..") 'http://blah.com/' urlparse.urljoin("http://blah.com/", "../") 'http://blah.com/../' urlparse.urljoin("http://blah.com/", "../..") 'http://blah.com/' Does the result make sense to you? Does it make sense that the last of these is shorter than the middle one? It sure doesn't to me. I thought it was obvious that there was an error;

That wasn't obvious at all to me. Now looking at the examples, I agree there is an error. The middle one is incorrect;

urlparse.urljoin("http://blah.com/", "../")

should also give 'http://blah.com/'.

You shouldn't be giving more "../" sequences than are possible. I find the current behavior acceptable. (Aparently for RFC 1808 that's a valid answer; it was an implementation choice in how to handle that case.)

There is still some text left to that respect in 5.4.2 of RFC 3986.

While not directly relevant, postings like John J Lee's http://mail.python.org/pipermail/python-bugs-list/2006-February/031875.html

The urlparse.urlparse() code should not be changed, for backwards compatibility reasons. strongly suggest a desire to not change that code.

This is John J Lee's opinion, of course. I don't see a reason not to fix such bugs, or to update the implementation to the current RFCs.

As this is not a bug, I have added the feature request 1591035 to SF titled "update urlparse to RFC 3986". Nothing else appeared to exist on that specific topic.

Thanks. It always helps to be more specific; being less specific often hurts. I find there is a difference between "urllib behaves non-intuitively" and "urllib gives result A for parameters B and C, but should give result D instead". Can you please add specific examples to your report that demonstrate the difference between implemented and expected behavior?

Regards, Martin

More information about the Python-Dev mailing list