API design question - `Response.url` about httpx HOT 8 CLOSED

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.

from httpx.

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

from httpx.

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.

from httpx.

how about:

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

from httpx.

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.

from httpx.

How about instead of maintaining backwards compatibility with requests, provide a series of codemods so people can upgrade their code to the new api?

from httpx.

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.

from httpx.

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.

from httpx.