Make 'raise_for_status' return the response object

This would make simple usages simpler:

``` python
result = requests.get("http://api.server.com/path").raise_for_status().json()
```


Thanks for this @vmalloc! I do not think we'll accept it at this time though. I'm on my phone at the moment but I'll be happy to give a more detailed explanation in a short while.


Ok, is it because it's incomplete or because this behaviour isn't desirable? 


This is a pretty drastic API change, and we're under an "API Freeze" at the moment. That API has been in place for almost two years now, and it changing it would break a lot of people's code :)

Also, Raise == Exception.

However, thanks so much for contributing! Keep 'em coming!


I'm just curious - how would it break people's code? Is anyone asserting it returns None?—
Rotem

On Thu, Jan 30, 2014 at 7:25 PM, Kenneth Reitz notifications@github.com
wrote:

> This is a pretty drastic API change, and we're under an "API Freeze" at the moment. That API has been in place for almost two years now, and it changing it would break a lot of people's code :)
> Also, Raise == Exception.
> 
> ## However, thanks so much for contributing! Keep 'em coming!
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/pull/1894#issuecomment-33710628


@vmalloc that isn't really the issue. There's a semantic meaning in the name `raise_for_status`. The meaning in it is that you want to raise an Exception for something that is not an okay status code (vaguely some status code < 400). There should be no explicit return from that method. There is an implicit return of `None` because any Python function (or method) written without a `return` returns `None`. The function has one purpose: raise an exception. Returning the response makes the API inconsistent -- which is why it is a breaking API change -- and it makes the meaning of the function nebulous.

I understand why you feel this change is desirable but it is not a change we can accept. We also will not accept an addition of a method to provide this behaviour. It isn't something that fits in with the overall design of requests.

Thanks for contributing though! :cake:


i know this PR is quite old, but i really like it!... mostly because IMO it is completely in sync with the `requests` package's main objective of reducing clutter. without this change, the following is required:

```
result = requests.get("http://api.server.com/path")
result.raise_for_status()
result = result.json()
```

isn't @vmalloc's version much cleaner? if the problem is the naming of `raise_for_status`, how about renaming it (with a deprecating alias)? e.g.:

```
result = requests.get("http://api.server.com/path").require_ok().json()
```

(or whatever you want) or how about a new option to all of the request methods:

```
result = requests.get("http://api.server.com/path", require_ok=True).json()
```

btw, i currently always monkey-patch `Response.raise_for_status` to do exactly this. ugly!


I frankly still don't understand the reason this was rejected. I don't
think this qualifies for "API breakage" per se, and the utility of this
change is enormous.

I suspect the pattern you mentioned is prevalent in 99% of the use cases.
On יום ו׳, 13 במאי 2016 at 0:08 metagriffin notifications@github.com
wrote:

> i know this PR is quite old, but i really like it!... mostly because IMO
> it is completely in sync with the requests package's main objective of
> reducing clutter. without this change, the following is required:
> 
> result = requests.get("http://api.server.com/path")
> result.raise_for_status()
> result = result.json()
> 
> isn't @vmalloc https://github.com/vmalloc's version much cleaner? if
> the problem is the naming of raise_for_status, how about renaming it
> (with a deprecating alias)? e.g.:
> 
> result = requests.get("http://api.server.com/path").require_ok().json()
> 
> (or whatever you want) or how about a new option to all of the request
> methods:
> 
> result = requests.get("http://api.server.com/path", require_ok=True).json()
> 
> btw, i currently always monkey-patch Response.raise_for_status to do
> exactly this. ugly!
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub
> https://github.com/kennethreitz/requests/pull/1894#issuecomment-218886371


+1 for this change, it would be very handy! 
`myjson = requests.get("http://api.server.com/path").raise_for_status().json()` is exactly what you want to write when dealing with REST API returning JSON objects.
I don't see the point of `raise_for_status()` renaming, because making it a chainable method does not change its semantics.

@guillp I agree. It's funny to me how this library willy-nilly broke compatibility time and again (e.g. with `json` turning to `json()`) but adding a single return value where there was none is a major backward compatibility issue...

Hi @vmalloc.

*Please* try to extend charity to the maintainers of OSS projects you use. We have not willy-nilly broken compatibility. The move from `json` to `json()` was accompanied by a major version bump and a substantial internal refactoring. Other breakages of compatibility have been considered to be bugs and errors and treated as such.

Ironically, I was previously inclined to look much more warmly on this proposal than my fellow maintainers. Now I'm not. The answer is no.