urllib.parse.urlparse output named tuples description is wrong for Python 3.9 and 3.10

The documentation for urllib.parse.urlparse states that:

The return value is a named tuple, which means that its items can be accessed by index or as named attributes, which are:

Attribute Index Value Value if not present

...

params 3 No longer used always an empty string

However it seems that the documentation does not reflect reality:

>>> 
>>> import urllib.parse
>>> p = urllib.parse.urlparse('http://foo.test/test;param')
>>> p
ParseResult(scheme='http', netloc='foo.test', path='/test', params='param', query='', fragment='')
>>> p[3]
'param'

and the returned named tuple has a populated params field.

The example and table changed to what they are now in gh-29816, but I cannot see any related changes in https://github.com/python/cpython/blob/main/Lib/urllib/parse.py which would make urlparse always return an empty string for params. I think the change to the table in gh-29816 is incorrect.

The example in the docs (urlparse("scheme://netloc/path;parameters?query#fragment")) shows correct output (params='') solely because "scheme" is not a scheme for which urlparse will parse the path params, per the list on line 59:

cpython/Lib/urllib/parse.py

Lines 59 to 61 in d7d7e6c

    
           uses_params = ['', 'ftp', 'hdl', 'prospero', 'http', 'imap', 
        
                          'https', 'shttp', 'rtsp', 'rtspu', 'sip', 'sips', 
        
                          'mms', 'sftp', 'tel']

urlparse checks if the scheme is in that list; if it isn't params will be an empty string, but in other cases it will be parsed from the URL:

cpython/Lib/urllib/parse.py

Lines 389 to 392 in d7d7e6c

    
           if scheme in uses_params and ';' in url: 
        
               url, params = _splitparams(url) 
        
           else: 
        
               params = ''

I find it a little confusing that params is only parsed for known schemes, but it's probably too late now to change it without breakage. The docs would benefit from clarification of when it is and isn't parsed, with an example to demonstrate the parsing.

And if params should be de-emphasized, wouldn't it make sense to reorganise the documentation to promote urlsplit instead (despite its worse naming), and mark urlparse, urlunparse, and ParseResult* as deprecated?

Also possibly urlunsplit, under the assumption that most users have stopped using raw tuples, and thus could just call geturl.

gh-91708: Revert params note in urllib.parse.urlparse table (#96699)

pythongh-91708: Revert params note in urllib.parse.urlparse table (py…

[3.11] gh-91708: Revert params note in urllib.parse.urlparse table (G…

[3.9] gh-91708: Revert params note in urllib.parse.urlparse table (GH…

[3.10] gh-91708: Revert params note in urllib.parse.urlparse table (G…

Thanks! ✨ 🍰 ✨

Merge branch 'main' into typewatch

pythongh-91708: Revert params note in urllib.parse.urlparse table (py…

[3.11] gh-91708: Revert params note in urllib.parse.urlparse table (G…

Navigation Menu

Repository navigation

`urllib.parse.urlparse` output named tuples description is wrong for Python 3.9 and 3.10 #91708

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	uses_params = ['', 'ftp', 'hdl', 'prospero', 'http', 'imap',
	'https', 'shttp', 'rtsp', 'rtspu', 'sip', 'sips',
	'mms', 'sftp', 'tel']

	if scheme in uses_params and ';' in url:
	url, params = _splitparams(url)
	else:
	params = ''

urllib.parse.urlparse output named tuples description is wrong for Python 3.9 and 3.10 #91708

Description

Activity

domdfcoding commented on Apr 20, 2022

xmo-odoo commented on Aug 29, 2022

ambv commented on Oct 7, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

`urllib.parse.urlparse` output named tuples description is wrong for Python 3.9 and 3.10 #91708