gh-63293: Deprecate providing false values besides strings or bytes to urllib.parse functions

[jacobtylerwalls]

bpo-19094 and bpo-22234

Previously, although truthy values failed with AttributeError: ... has no attribute 'decode', falsy values such as [] were silently accepted.

Original patch by @vajrasky.

---

I noticed in 3.11 (d597fdc) some inappropriate types will fail first in urlsplit() (only) via the @functools.lru_cache decorator requiring hashable types. This is the chief reason for rotating unsupported types in the test cases.

>>> import urllib.parse
>>> urllib.parse.urlsplit([])
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: unhashable type: 'list'
>>> urllib.parse.urlsplit(())
SplitResultBytes(scheme=b'', netloc=b'', path=b'', query=b'', fragment=b'')

https://bugs.python.org/issue19094

• Issue: urljoin should raise a TypeError if URL is not a string #63293

Closes #63293

[jacobtylerwalls]

I just did a bpo search for duplicates and found bpo-22234. The discussion eventually came round to a similar solution after discussing the necessity of a deprecation period (believe the consensus = not needed).

But in looking at the discussion there I realized it's safe to extend this solution to the other functions in the module and just factor this TypeError out to _coerce_args(). DRY is good. Will push again and update title and body.

[jacobtylerwalls]

The failing test is caused by pip relying on the undocumented duck-typing in question:

https://github.com/pypa/pip/blob/main/src/pip/_internal/models/link.py#L150-L154

I'll raise a PR against pip. So this may need to wait, unless we add a friendly shim.

Notice that the other patch in bpo-22234 explicitly regarded this as an error condition:

+        with self.assertRaises(TypeError):
+            urlunsplit(("http", "www.python.org", "", "", None))

Update: pip merged my PR: pypa/pip#10064

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[jacobtylerwalls]

From the failing docs job, I see requests relies on this behavior. I'll change to a emit a deprecation warning. Serhiy has a draft patch on bpo-22234 doing something similar. That patch also allows duck-typing for types having an "encode" attribute.

[MaxwellDupre]

Looks ok.

[jacobtylerwalls]

@orsenthil I'm wondering if you have a view as a maintainer of urllib?

Previously, values other than strings or bytes either failed cryptically with AttributeError if truthy or were accepted silently if falsy. In 3.11 one falsy value will now start failing cryptically with TypeError, described in OP.

Is this a useful cleanup? I included a deprecation path for the falsy values.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[jacobtylerwalls]

Marking as draft until I can allow NoneType after changes in c5cfcdf.