A Session object now maintains a response hook property...

...for the most recent request.

This pertains to issue at https://github.com/kennethreitz/requests/issues/1271


You're re-calling the hook. We dispatch hooks elsewhere now. If you want this to be accepted at all, you'll need to set the response attribute in `Session#send`. It would also be nice if you stripped this commit from your repository and force-pushed the new commit with that to the same branch so the Pull Request will automatically update itself.

Until you do that, I'm :-1: on this. After you do that I'll be entirely indifferent. You might also add a test to make sure we don't accidentally remove this again.


Thanks for your quick response and advice. By stripping the commit from my repo, do you mean that I should do something like `git reset --hard HEAD~1` locally, make my code changes, and then do a push with --force to replace what's currently on my branch?


That's exactly it. :-)


I'm -1 on this. I see no reason to clutter the session object with something that is about to be returned from it. Why is it not sufficient to save the response?


One current use case I have is a class that maintains a Session object as one of its properties. I've found that it's incredibly useful to have the most recent response available at any given time (after at least one request has been made), especially for debugging and logging purposes. While it's totally possible, of course, to put something like `self.last_response =` before every Session get/post call, it's a lot more convenient if the session keeps track of the response without having to write duplicate code everywhere--the more like a browser it is, the more human-friendly it is.


I agree that it's convenient, but I don't agree with the last statement. The notion of Requests as a library "for humans" rests with its simplicity, not its utility. The original versions of Requests could do very little, but they were still "for humans" because their API was simple and they were concerned with doing the right thing, not with the spec.

The short answer is that this is unlikely to be accepted. This is a change to the Requests API, which are never accepted without good reason. This is neither hard to implement nor overwhelmingly popular, so it's unlikely to be merged. In the meantime, I suggest you do this:

``` python
from requests import Session

class StorageSession(Session):
    def send(self, request, **kwargs):
        r = super(StorageSession, self).send(request, **kwargs)
        self.last_response = r
        return r
```

This provides all the function you need without any code reuse, and without adding anything to Requests' API. =)


I agree with @lukasa. In fact to expand a bit on his point about the last statement I'll say this: 

We emulate browser behaviour in some instances because in spite of the relevant RFC some servers will only behave "correctly" where "correctly" is how browsers expect it to behave. In those cases, RFC be damned, that's how we have to behave but at no point is requests a replacement for a browser, or a programmatic browser. Were that the case, we would have to keep a session history tracing back to the very first request. We provide histories for individual requests because being able to know that a redirect occurred is very important. It isn't so important on a session.

I was and remain frankly -0 on this because this existed well into 1.x (I think until 1.1.0) but when we asked if anyone was using it, no one replied until now. If it isn't used, it is just causing code-smell and will only cause confusion for future editors of and contributors to the project.

@Lukasa's solution is elegant and works very well. Even easier might be a hook like so:

``` python
import requests
from functools import partial

def _hook(session, response, **kwargs):
    session.response = response
    return response

s = requests.Session()
hook = partial(hook, s)
s.hooks['response'] = [hook]

r = s.get('https://httpbin.org/get')
r.url == s.response.url
```

Admittedly I don't have the time to test that, but I'm 90% sure it will work. :)


This is admittedly off-topic, but I don't think there's enough currying in Requests code examples. More currying! :curry: 


More of the off-topic discourse: So many people hate currying, but when done in moderation it is SO useful.


Thanks for the examples; I'll consider them if this PR doesn't go through.

@sigmavirus24: When/where was it asked if anyone was using this response property? I didn't even hear about it until I started pulling straight from github (rather than PyPI).


I believe I asked the question on GitHub and at least Kenneth retweeted. We also polled the IRC channel. No one responded in the affirmative to either.


Cool, thanks.


They're far from ideal methods, but it's impossible to contact everyone.