[Python-Dev] Path object design

["Martin v. Löwis"]

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