Status Code Names/Descriptions

This pull request adds printable names for status codes, as both the `requests.status_codes.name` dictionary, and accessible directly from a Response object as `Response.status_name`.

I think it's quite a useful thing to have, say for printing out a name to go with a given status code (especially in the event of a failure.

And uses cases:

``` python
>>> import requests

>>> r = requests.get('https://github.com/timeline.json')
>>> r.status_code
200
>>> r.status_name
'OK'

>>> r = requests.get('https://github.com/timene.js')
>>> r.status_code
404
>>> r.status_name
'Not Found'
>>> r  # I also added the status_name to __repr__'s output, so the below is easier to understand at a glance
<Response [404: Not Found]>

>>> requests.status_codes.name[200]
'OK'

>>> requests.status_codes.name[203]
'Non-Authoritative Info'

>>> requests.status_codes.name[405]
'Method Not Allowed'
```

We may even want to add a `requests.status_codes.description` dict later on, having something like a one sentence description of what the code means. Maybe even create a Status class, with the members `code`, `name`, and `description`, accessible as `Response.status`, so you'd do something like this instead:

``` python
>>> r = requests.get('https://github.com/timene.js')
>>> r.status.code
404
>>> r.status.name
'Not Found'
```

Thanks for the awesome library. I dunno how I ever lived without Requests :smile: 


I'm actually quite interested to see what you guys think about that `Status` object idea, at the end of the description up there.

Keeping a shim so that `Response.status_code` gets/sets the value of Response.status.code would be quite simple, and I think that it's cleaner than adding a `Response.status_name` object now, and then looking into converting this over to a single `Status object later.


Alright, I implemented that idea above, because it's just a bunch nicer. Including adding the `descriptions` dict to `requests.status_codes`. Most of the descriptions are almost directly taken or adapted from the [Mozilla Wiki](https://developer.mozilla.org/en-US/docs/HTTP/HTTP_response_codes) and [Wikipedia](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes), commented out where I will go back and add it later.

So, the updated use case code:

``` python
>>> import requests

>>> r = requests.get('https://github.com/timeline.json')
>>> r.status_code  # old method still works
200
>>> r.status.code
200
>>> r.status.name
'OK'
>>> r.status.description
'Request was successful.'

>>> r = requests.get('https://github.com/timene.js')
>>> r.status.code
404
>>> r.status.name
'Not Found'
>>> r  # I also added the status_name to __repr__'s output, so the below is easier to understand at a glance
<Response [404: Not Found]>

>>> requests.status_codes.name[200]
'OK'

>>> requests.status_codes.name[203]
'Non-Authoritative Info'

>>> requests.status_codes.name[405]
'Method Not Allowed'

>>> requests.status_codes.description[401]
'Authentication is needed to access the given resource.'

>>> requests.status_codes.description[405]
'Server has disabled this request method and cannot be used.'
```

I have yet to add descriptions for all the status codes, but if `r.status.description` does not have a description, it simply returns an empty string.


I like it.


Thanks for the pull request! We're always delighted to have new submissions.

Unfortunately, I don't think this PR will be accepted. There are a few reasons for this.

First, Requests is in [feature freeze](http://docs.python-requests.org/en/latest/dev/todo/#feature-freeze), which means new features are highly unlikely to be accepted, unless they provide significant value to the library. Sadly, I don't believe this PR does.

Second, it should be noted that the short descriptions already work without this PR:

``` python
>>> import requests
>>> r = requests.get('http://www.google.com/')
>>> r.status_code
200
>>> r.reason
'OK'
>>> r = requests.get('http://www.lukasa.co.uk/deliberate_404')
>>> r.status_code
404
>>> r.reason
'NOT FOUND'.
```

With this in mind, the feature added by this PR is the long-form descriptions. I honestly don't think that anyone programming HTTP is going to be overly put out by having to use Wikipedia to look up a status code. I can see some use for these codes in printed errors, but anyone intending to provide nicely-formatted errors on Requests will already have to write custom code, so I don't think this is too much of a burden.

**I will not close this** because Kenneth might disagree with me, but I don't think he will on this one. 


Ah, I assumed the feature freeze only applied to API-breaking changes — that's fair enough.

Short descriptions already work, but these are more inclined towards printable names and descriptions, such as with the following code:

``` python
r = requests.get(url, **kwargs)

if not r.ok:
    return 'HTTP Error: {code} {name} - {description}'.format(code=r.status.code,
                                                   name=r.status.name,
                                                   description=r.status.description)
```

Which would show the user something like this, without having to get a description from somewhere else:

```
HTTP Error: 404 Not Found - Server cannot find requested resource.
```

But I totally understand if this wouldn't provide enough value to benefit everyone. Thanks for the prompt response!


I agree that for some users this would provide a great deal of value, and I'd totally support you maintaining a third-party implementation of this. Unfortunately, as I said, it's not suitable for the main library in this feature freeze.

As I said, it's great that you submitted code, contributors are always great to have, even if we don't end up using their code. =)


I agree with @Lukasa. 

However, the reverse lookup is something I've wanted to add for a while:

``` pycon
>>> requests.codes.name[200]
'OK'
```


Fair enough. In that case, I'm gonna break this out to a separate package, [http_status](https://pypi.python.org/pypi/http-status)

And don't worry, I understand. I actually have one or two really simple fixes to submit after I get this broken out to another package. Thanks again for the quick response. =)