Repository navigation
API design question - Response.url #113
Description
Currently our Response.url attribute exposes a URL instance.
This is a breaking change from the requests API where it just exposes a plain string.
It's feasible that we should instead only be exposing plain string URLs, in order to aim for drop-in replacement API compatibility w/ requests, and in order to keep the API surface area low.
Options here are:
- Expose
request.urlas a URL instance. (Richer information, URL class is also useful in its own right.) - Expose
request.urlas a str. (Better API compat. Lower API surface area to maintain.) - Expose
request.urlas a str, andrequest.urlinfoas a URL instance. (Better API compat. High API surface area.)
Activity
lovelydinosaur commentedon Jul 9, 2019
If we do keep it as a URL instance, then one option to keep closer API compat would be to allow string comparisons, eg
URL(“https://www.encode.io/“) == “https://www.encode.io/“That has the advantage of being string-like, and far less likely to introduce any API breakage.
sethmlarson commentedon Jul 9, 2019
I'm for allowing string comparisons and providing the read-only URL instance. :) Seems like something users are probably doing themselves and shouldn't have to.
lovelydinosaur commentedon Jul 9, 2019
Seems like it's probably the best all round option yeah.
graingert commentedon Jul 10, 2019
how about:
sethmlarson commentedon Jul 10, 2019
I'd say that flags / parameters that massively alter the behavior of a function should probably be avoided.
Typically what a lot of URL instance classes do to recover the original string for the URL is provide an
.unsplit()method.graingert commentedon Jul 11, 2019
How about instead of maintaining backwards compatibility with requests, provide a series of codemods so people can upgrade their code to the new api?
sethmlarson commentedon Jul 11, 2019
We'll definitely need a section in the documentation on migration strategy, especially from requests but also useful to how for instance urllib3 does something compared to http3.
StephenBrown2 commentedon Jul 14, 2019
Personally I am quite in favor of the
URLclass, and am currently using urlpath for approximately the same function, including the ability to concatenate parts with/. MakingURLinstances string comparable (and bonus:/concat-able!) would be the best option I think, giving the best of both worlds.