Keep the API style consensus for request model in httpx

[Zheaoli]

We now have a different API style, like the following code, between the non-stream and stream requests.

resp = httpx.get("http://demo")
resp.raise_for_status()

with httpx.stream("http://demo") as resp:
       resp.raise_for_status()

I prefer we keep the consensus API style as the developer does in the requests lib.

with requests.get("http://demo") as resp:
        resp.raise_for_status()

with requests.get("http://demo", stream=True) as resp:
       resp.raise_for_status()

We can reach this target by two different ways:

1. use contextmanager decorator in every request method in client
2. add __enter__ and __exit__ (__aenter__ and __aexit__ for async), just like the requests, FYI https://github.com/psf/requests/blob/main/requests/models.py#L706-L711

I think there would be two benefits we can get from this feature:

1. a better API style
2. we make it easier for the people who want to switch the requests to the httpx.

[CNSeniorious000]

In Requests Compatibility:

HTTPX provides a .stream() interface rather than using stream=True. This ensures that streaming responses are always properly closed outside of the stream block, and makes it visually clearer at which points streaming I/O APIs may be used with a response.

This seems to be the intended design.

But I do agree with your idea, because I think stream=True is essentially just a parameter of the request, while the method of the request is the essence. On the other hand, the inconsistency of the API does make it difficult to migrate from the requests library. At the same time, having both client.stream and client.xxx(stream=True) APIs should not cause backward incompatibility.

[lovelydinosaur]

It's absolutely a deliberate design decision.

Having a stream=True parameter is a code-smell, and lets you do two different kinds of broken things...

with client.get("https://www.example.com") as response:
    # The response isn't actually open here, but the code makes it look like it is.
    ...

...or this case, which is worse...

response = client.get("https://www.example.com", stream=True)
# We'd better close the response or we'll end up with a hanging connection in the connection pool.

We've deliberately opted for a more constrained style here that is always explicit about when a streaming response is opened and closed.