[Python-Dev] Path object design
"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/", "..")
>>>> urlparse.urljoin("http://blah.com/", "../")
>>>> urlparse.urljoin("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
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
>> 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?
More information about the Python-Dev