The following example in Doc/library/urlparse.rst is wrong

>>> urlparse('www.cwi.nl:80/%7Eguido/Python.html')
ParseResult(scheme='', netloc='', path='www.cwi.nl:80/%7Eguido/Python.html',
           params='', query='', fragment='')

In the actual output, scheme='www.cwi.nl'.

In addition, the preceding text is confusing and probably not grammatical:

"""
Otherwise, it is not possible to distinguish between netloc and path components, and would the indistinguishable component would be classified as the path as in a relative URL.
"""

Discovered while working on issue 10225.

Looks like I've been beaten again by make doctest picking up older python, but something is not right here:

In Python 2.6.5:


>>> urlparse('www.cwi.nl:80/%7Eguido/Python.html')
ParseResult(scheme='www.cwi.nl', netloc='', path='80/%7Eguido/Python.html', params='', query='', fragment='')

but in 2.7:

>>> urlparse('www.cwi.nl:80/%7Eguido/Python.html')
ParseResult(scheme='', netloc='', path='www.cwi.nl:80/%7Eguido/Python.html', params='', query='', fragment='')


and the text preceding the example in the doc does not really tell which is right.

I think this is correct: it is the new behavior after the fix for #754016 was committed.

On Fri, Oct 29, 2010 at 2:15 AM, Georg Brandl <report@bugs.python.org> wrote:
..
> I think this is correct: it is the new behavior after the fix for #754016 was committed.
>

I agree.  I kept the issue open because I cannot parse

"""
Otherwise, it is not possible to distinguish between netloc and path
components, and would the indistinguishable component would be
classified as the path as in a relative URL.
"""

That's for Senthil to rephrase as intended :)

-   Otherwise, it is not possible to distinguish between netloc and path
-   components, and would the indistinguishable component would be classified
-   as the path as in a relative URL.
+   If the netloc does not start with '//', the module cannot distinguish it
+   from path and it would classify it as path component in the relative url.

How does this sound?

// is not part of the netloc in RFC terms, it’s a delimiter between components

How about this:

-  If the scheme value is not specified, urlparse following the syntax
-  specifications from RFC 1808, expects the netloc value to start with '//',
-  Otherwise, it is not possible to distinguish between net_loc and path
-  component and would classify the indistinguishable component as path as in
-  a relative url.

+  Following the syntax specifications in RFC 1808, urlparse recognizes
+  a netloc only if it is properly introduced by '//'.  Otherwise the
+  input must be presumed to be a relative URL and thus to start with
+  a path component.


However, it seems to me there is a bug here:

>>> urlparse.urlparse('www.k.com:80/path')
ParseResult(scheme='', netloc='', path='www.k.com:80/path', params='',
query='', fragment='')
>>> urlparse.urlparse('www.k.com:path')
ParseResult(scheme='www.k.com', netloc='', path='path', params='',
query='', fragment='')

I think the second one is correct and that the first one should produce

ParseResult(scheme='www.k.com', netloc='', path='80/path', params='',
query='', fragment='')

I haven't read all the way through the RFC again, though.  But *one*
of the above is wrong.

Fixed the wordings in r86296(py3k), r86297(release31-maint) and r86298(release27-maint).

David, for the examples you mentioned, the first one's parsing logic follows the explanation that is written. It is correct.

For the second example, the port value not being a DIGIT exhibits such a behavior.  I am unable to recollect the reason for this behavior. 
Either the URL is invalid (PORT is not a DIGIT, and parse module is simply ignoring to raise an error - it's okay, given the input is invalid) or it needs to distinguish the ':' as a port separator from path separator for some valid urls.

I think, if we find a better reason to change something for the second scenario, we shall address that.

Senthil, no it isn't.  There is no way to know a priori that ':80' represents a port number rather than a path, absent the // introducer for the netloc.

This bug is fixed; I ought to open a new one for the path thing but perhaps I will wait for a user report instead :)