The documentation of urlparse in Python2 and urllib.urlparse in Python3 
refers to three RFC's, the last of which (RFC 2396) says that it 
supersedes the other two and, in fact, clicking on the links to the other 
two doesn't work; the link and description for the two obsolete RFCs 
should be removed.

More precisely, RFC 1738 and 1808 are updated by RFC 2396, which is in
turn obsoleted by RFC 3986 (which obsoletes 1808 too but only updates
1738). Eliminating the obsoleted ones leaves us with two references,
RFC 1738 and RFC 3986. I’m going to remove all references to RFCs other
that these two (I understand from test_urlparse that urlparse actually
conforms to RFC 3986, that’s a good thing). I’m going to replace some
instances of “URL” with “URI” where appropriate (only in the
documentation, not in modules or functions names). 

Besides, all three links work for me.

Sorry, my logic was flawed: RFC 1808 is not obsoleted either, so it
leaves us with 1738, 1808 and 3986.

Included patch for this issue. There is some diff noise because of
paragraph wrapping. I don’t know whether my seealso addition is
correctly formatted (the title spans two lines) because of a Sphinx bug
on my machine. Thanks for reviewing.

Georg, shall I take up this one?

Yes, you've probably a better understanding of what differentiates an
URL and URI than me :)

See also #2987

Fixed in revision 80146 and merged into other branches
release26-maint: r80147
py3k: r80148
release31-maint: r80149

The 'See also' in the documentation should also be updated:
http://docs.python.org/dev/library/urlparse.html#urlparse.urldefrag

Updated in the r80336 through r80339. Thanks for the note, Ezio.

Hello

You’ve added references to current RFCs without removing obsolete ones. Why not remove mention of obsoleted RFCs?

Regards

It was intentional as not to remove the old RFC references because
certain parsing behaviours follow them compatibility purposes. If you
look at test_urlparse.py you might get the specifics of parsing
corresponding a RFC.

Thanks for the explanation. Would it make sense to have either different
functions or a switch to existing ones to tell if we want legacy or
modern parsing?

On Thu, Apr 22, 2010 at 11:08:01AM +0000, Éric Araujo wrote:
> Thanks for the explanation. Would it make sense to have either different
> functions or a switch to existing ones to tell if we want legacy or
> modern parsing?

Hard at the moment, or is it a bleeding requirement? I doubt. 
But what is worth is full compliance on all scales with STD 66.

(Not sure I understand “bleeding requirement”, but I get the gist.)

Full compliance with STD 66 is indeed the most desirable goal, thanks
for your work in that direction! I just thought that some corner cases
were not compliant because of backwards compat (hence the disabled tests
in test_urlparse).

Regards