missing Response.ok method

[codenoid]

resp.ok is cute

[lovelydinosaur]

We've got a comment in the "requests compatibility" docs about this.

[StephenBrown2]

Link to aforementioned docs: https://www.python-httpx.org/compatibility#checking-for-4xx5xx-responses

[serg06]

if not resp.is_error just doesn't hit the same as if resp.ok 🙁

[Colin-b]

See https://github.com/encode/httpx/issues/809

I fail to see a use case were you would want to discard any errors (no logs, no treatment at all) and only perform action in case of successful response. This would be the only use case for a if response.ok and it seems like bad practice. Do you have such use case ?

[serg06]

See #809

I fail to see a use case were you would want to discard any errors (no logs, no treatment at all) and only perform action in case of successful response. This would be the only use case for a if response.ok and it seems like bad practice. Do you have such use case ?

I don't, I'm just a sassy opinionated coder

[Colin-b]

See #809
I fail to see a use case were you would want to discard any errors (no logs, no treatment at all) and only perform action in case of successful response. This would be the only use case for a if response.ok and it seems like bad practice. Do you have such use case ?

I don't, I'm just a sassy opinionated coder

So you don't need to use if not, you can replace your:

import httpx

response = httpx.get()
if not response.is_error:
    handle_success()
else:
    handle_error()

by:

import httpx

response = httpx.get()
if response.is_error:
    handle_error()
else:
    handle_success()

And then you have it, no negation involved :)

[serg06]

And then you have it, no negation involved :)

But then I'd be putting the (unlikely) error case before the (likely) success case!

[lovelydinosaur]

if not resp.is_error just doesn't hit the same as if resp.ok 🙁

Them's the breaks.

[lovelydinosaur]

So, the reason we don't do this is pretty clear.
As a developer, what do you think response.ok means?

• response.status_code == 200 A "200 OK" response
• response.status_code >= 200 and response.status_code <= 299 Any 2xx response
• not response.is_error Not a "4xx, 5xx" response

It's just not at all clear. (Incidentally, in requests it means the last one of those.)

I could perhaps see us having response.is_success, response.is_client_error and response.is_server_error properties., which are way more obviously 2xx, 4xx, and 5xx classes of response. But... note that would open up easy coding error classes like...

response = httpx.get("https://www.example.com", allow_redirects=False)
if response.is_success:
    ...  # Success condition
else:
    ...  # Error condition

Which doesn't do what it might look like it does on first sight.

So... sure if not response.is_error ain't got as much sass as if response.ok, or even if response.is_success, but it'll help prevent coding errors.

(I mean there's other options too. For instance, response.is_2xx, response.is_3xx, etc... but in terms of requests-parity I'm pretty convinced we don't want the misleading response.ok)