ryanmcgrath/twython — pull request #74 by jvanasco (2012-04-08 22:51:08+00:00)
Title: debugging support

i added some support for debugging issues with twython

i'm not sure how/where the tests are , i would have written some to your harness if i did.

full details below, but...

1- tests the API response to ensure it's valid, throws a TwythonError with details if needed.
2- stashes the info from the last api request -- so you can inspect and try to figure out what happened.
3- added benefit - you have access to the headers that described ratelimiting status

---

- added twitter's http status codes to twitter_endpoints.py ( dict index on status code, value is a tuple of name + description )
- created an internal stash called '_last_call' that stores details of the last api call ( the call, response data, headers, url, etc )
- better error handling for api issues:
- - raises an error when the status code is not 200 or 304
- - raises TwythonAPILimit when a 420 rate limit code is returned
- - raises a TwythonError on other issues, setting the correct status code and using messages that are from the twitter API
- wraps a successful read in a try/except block. there's an error i haven't been able to reproduce where invalid content can get in there, it would be nice to catch it and write a handler for it. ( the previous functions were all introducted to allow this to be debugged )
- added a 'get_lastfunction_header' method. if the API has not been called yet , raises a TwythonError. otherwise it attempts to return the header value twitter last sent. useful for x-ratelimit-limit , x-ratelimit-remaining , x-ratelimit-class , x-ratelimit-reset