You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Obsolete RFCs should be removed from doc of urllib.urlparse #49900
urlparse.diff: First attempt: corrected RFC references and “URL” usage
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/orsenthil'closed_at=<Date2010-04-22.06:04:45.179>created_at=<Date2009-04-01.16:14:16.272>labels= ['easy', 'type-bug', 'docs']
title='Obsolete RFCs should be removed from doc of urllib.urlparse'updated_at=<Date2010-04-22.11:36:20.115>user='https://github.com/MLModel'
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).
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.
changed the title [-]Obsolete RFC's should be removed from doc of urllib.urlparse[/-][+]Obsolete RFCs should be removed from doc of urllib.urlparse[/+]on Apr 11, 2010
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).
Activity
MLModel commentedon Apr 1, 2009
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.
merwok commentedon Apr 25, 2009
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.
merwok commentedon Apr 25, 2009
Sorry, my logic was flawed: RFC 1808 is not obsoleted either, so it
leaves us with 1738, 1808 and 3986.
merwok commentedon Apr 25, 2009
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.
orsenthil commentedon May 1, 2009
Georg, shall I take up this one?
birkenfeld commentedon May 1, 2009
Yes, you've probably a better understanding of what differentiates an
URL and URI than me :)
merwok commentedon Apr 11, 2010
See also bpo-2987
[-]Obsolete RFC's should be removed from doc of urllib.urlparse[/-][+]Obsolete RFCs should be removed from doc of urllib.urlparse[/+]orsenthil commentedon Apr 17, 2010
Fixed in revision 80146 and merged into other branches
release26-maint: r80147
py3k: r80148
release31-maint: r80149
ezio-melotti commentedon Apr 19, 2010
The 'See also' in the documentation should also be updated:
http://docs.python.org/dev/library/urlparse.html#urlparse.urldefrag
orsenthil commentedon Apr 22, 2010
Updated in the r80336 through r80339. Thanks for the note, Ezio.
merwok commentedon Apr 22, 2010
Hello
You’ve added references to current RFCs without removing obsolete ones. Why not remove mention of obsoleted RFCs?
Regards
orsenthil commentedon Apr 22, 2010
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.
merwok commentedon Apr 22, 2010
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?
orsenthil commentedon Apr 22, 2010
On Thu, Apr 22, 2010 at 11:08:01AM +0000, Éric Araujo wrote:
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.
merwok commentedon Apr 22, 2010
(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