Feature: please add a "status" field to response object which confirms to PEP 0333

According to this:
https://www.python.org/dev/peps/pep-0333/#the-start-response-callable

The response object must contain a status field with string values such as "200 OK" or "403 Forbidden" and so forth.  If one is developing a Python WSGI compliant API then any framework used (such as falcon) is going to require a status field is set correctly.

I am deploying a python app behind WSGI (falcon) and I use the requests module to perform requests on behalf of the API consumer (it's a special use case to sign requests going to Amazon Elasticsearch using signature 4 that I did not want to try to write in JavaScript) and as a result I have to take the response object from requests and take values contained within to construct a WSGI compliant response.

Currently I have to concatenate the status_code and reason fields from the requests response object to in order to construct a PEP 0333 complaint response status.  A field added to the requests response object would save this extra step.

This is a "nice to have", not a serious priority.


Thanks for this request @eric-tucker!

Unfortunately, Requests is in feature-freeze for the foreseeable future, which means that we're generally not implementing new features unless they represent a really compelling loss of function. Given that all the information you require is present, and that a helper function to build this information is exactly one line long, I'm afraid I don't think this feature is a priority for us at this time.

Sorry we can't be more help!


I understand, but can you elaborate on why you're in a "feature-freeze"?

Is the product no longer actively developed?


Well, [our documentation](http://docs.python-requests.org/en/latest/dev/contributing/#feature-requests) talks about this a little bit, but allow me to elaborate.

Requests is not a project that aims to have every feature that a user can imagine. From our perspective, tools like curl are better suited to that. The reason we don't want to add lots of features is because each feature added complicates the API, and our API is sacred to us. It is the foundation on which Requests is built, and our overwhelming primary concern.

Requests is still actively developed: we will fix bugs as soon as they're reported, and add any glaring feature omissions if they're pointed out to us. But, fundamentally, we believe that Requests already covers 80% of what people need from it.

Generally speaking, then, we start at a -1 on any feature request. If the feature is both simple to implement outside of requests (like this one), required by relatively few users (also like this one), and has few-or-no pitfalls for unsuspecting users (also like this one), then our overwhelming inclination is to leave that feature out. Features represent an ongoing maintenance burden to the maintainers and a complexity cost to users, who need to navigate a maze of documentation of features they don't care about to find the few that they do. That's just not how we do things here.

For perspective, our feature freeze has been in place since v1.0.0 was released. Clearly, that has not stopped development of Requests. Don't worry, we're still here still supporting new Python versions and fixing bugs. We're just not willing to become libcurl for Python.


OK.  

As long as I can be guaranteed that this:

```
response.status = str(return_result.status_code) + " " + return_result.reason
```

will always give me a PEP 0333 compliant status then I'm fine with things as they are.

Thanks!


That will remain true as long as HTTP/2 is unsupported by Requests.

However, in HTTP/2 there are no reason phrases. If we ever support HTTP/2, then `.reason` may return the empty string. Just a warning.