| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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 |
Sorry, something went wrong.
|
This PR is stale because it has been open for 30 days with no activity. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
There was a problem hiding this comment.
Looks ok.
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
|
This PR is stale because it has been open for 30 days with no activity. |
Sorry, something went wrong.
…or inappropriate types
Documentation build overview271 files changed · + 9 added · ± 261 modified · - 1 deleted + Added
± Modified
- Deleted |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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.
https://bugs.python.org/issue19094
Closes #63293
Closes #66430