FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

gh-63293: Deprecate providing false values besides strings, bytes, or `None` to urllib.parse functions by jacobtylerwalls · Pull Request #26687 · python/cpython · GitHub

/ cpython Public

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

Open
jacobtylerwalls wants to merge 11 commits into
python:mainfrom
jacobtylerwalls:urllib-typeerror
Open

gh-63293: Deprecate providing false values besides strings, bytes, or None to urllib.parse functions#26687
jacobtylerwalls wants to merge 11 commits into
python:mainfrom
jacobtylerwalls:urllib-typeerror

Conversation

jacobtylerwalls commented Jun 12, 2021
edited
Loading

Copy link
Copy Markdown
Contributor

bpo-19094 and bpo-22234

Like a recent change in parse_qsl() (#116903) to require strings, bytes, or None, require this in other urllib.parse functions as well, with a deprecation cycle for false values.

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

Closes #63293
Closes #66430

Comment thread Lib/urllib/parse.py Outdated

jacobtylerwalls commented Jun 13, 2021
edited by bedevere-bot
Loading

Copy link
Copy Markdown
Contributor Author

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 changed the title bpo-19094: Raise TypeError in urljoin(), urlparse(), and urlsplit() for inappropriate types bpo-19094: Raise TypeError in urllib.parse for inappropriate types Jun 13, 2021

jacobtylerwalls commented Jun 13, 2021
edited
Loading

Copy link
Copy Markdown
Contributor Author

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

This comment was marked as outdated.

jacobtylerwalls changed the title bpo-19094: Raise TypeError in urllib.parse for inappropriate types bpo-19094: Raise TypeError in urllib.parse for objects besides strings or bytes Jun 14, 2021

Copy link
Copy Markdown

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

github-actions Bot added the stale Stale PR or inactive for long period of time. label Jul 15, 2021

jacobtylerwalls commented Feb 23, 2022
edited by bedevere-bot
Loading

Copy link
Copy Markdown
Contributor Author

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.

jacobtylerwalls changed the title bpo-19094: Raise TypeError in urllib.parse for objects besides strings or bytes bpo-19094: Deprecate providing false values besides strings to urllib.parse functions Feb 23, 2022
jacobtylerwalls changed the title bpo-19094: Deprecate providing false values besides strings to urllib.parse functions bpo-19094: Deprecate providing false values besides strings or bytes to urllib.parse functions Feb 23, 2022

MaxwellDupre left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Looks ok.

jacobtylerwalls changed the title bpo-19094: Deprecate providing false values besides strings or bytes to urllib.parse functions gh-63293: Deprecate providing false values besides strings or bytes to urllib.parse functions Jun 18, 2022
github-actions Bot removed the stale Stale PR or inactive for long period of time. label Aug 9, 2022

Copy link
Copy Markdown
Contributor Author

@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.

arhadthedev added stdlib Standard Library Python modules in the Lib/ directory python labels Nov 19, 2023
arhadthedev added the 3.13 bugs and security fixes label Nov 19, 2023
pablogsal requested review from pablogsal and removed request for pablogsal November 19, 2023 17:39

github-actions Bot commented Apr 9, 2026

Copy link
Copy Markdown

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

github-actions Bot added the stale Stale PR or inactive for long period of time. label Apr 9, 2026

This comment was marked as resolved.

jacobtylerwalls marked this pull request as draft April 20, 2026 19:57
github-actions Bot removed the stale Stale PR or inactive for long period of time. label May 10, 2026

read-the-docs-community Bot commented Jul 12, 2026
edited
Loading

Copy link
Copy Markdown

jacobtylerwalls marked this pull request as ready for review July 12, 2026 01:28
jacobtylerwalls changed the title gh-63293: Deprecate providing false values besides strings or bytes to urllib.parse functions gh-63293: Deprecate providing false values besides strings, bytes, or None to urllib.parse functions Jul 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3.13 bugs and security fixes awaiting review stdlib Standard Library Python modules in the Lib/ directory

Projects

None yet

Development

Successfully merging this pull request may close these issues.

urllib.parse.urlparse accepts any falsy value as an url urljoin should raise a TypeError if URL is not a string

9 participants


Back | FazBrowse Home | New Git URL