Httpx: API design question - `Response.url`

[tomchristie]

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.url as a URL instance. (Richer information, URL class is also useful in its own right.)
• Expose request.url as a str. (Better API compat. Lower API surface area to maintain.)
• Expose request.url as a str, and request.urlinfo as a URL instance. (Better API compat. High API surface area.)

[tomchristie]

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]

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.

[tomchristie]

Seems like it's probably the best all round option yeah.

[graingert]

how about:

with http3.Session(requests_compat=True) as s:
    assert type(s.get("https://example.com").url) is str

[sethmlarson]

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]

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]

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]

Personally I am quite in favor of the URL class, and am currently using urlpath for approximately the same function, including the ability to concatenate parts with /. Making URL instances string comparable (and bonus: / concat-able!) would be the best option I think, giving the best of both worlds.