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

[dnicolodi]

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.

[domdfcoding]

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.

[xmo-odoo]

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.