Maybe the twitter_http_status_codes were a good idea. :P

I still think it's weird to have them, but I'm not against giving the
user more information. I put back in the twitter_http_status_codes
variable, but I changed where the logic was being handled, instead of
it happening the in _request, it will be asserted in Twython error if
an error_code is passed AND the error_code is in
twitter_http_status_codes
This commit is contained in:
Michael Helmick 2012-04-09 10:59:13 -04:00
parent eb22296e33
commit 813626a9ad
2 changed files with 21 additions and 3 deletions

View file

@ -27,7 +27,7 @@ except ImportError:
# Twython maps keyword based arguments to Twitter API endpoints. The endpoints
# table is a file with a dictionary of every API endpoint that Twython supports.
from twitter_endpoints import base_url, api_table
from twitter_endpoints import base_url, api_table, twitter_http_status_codes
# There are some special setups (like, oh, a Django application) where
@ -64,8 +64,11 @@ class TwythonError(AttributeError):
def __init__(self, msg, error_code=None):
self.msg = msg
if error_code is not None:
self.msg = self.msg + ' Please see https://dev.twitter.com/docs/error-codes-responses for additional information.'
if error_code is not None and error_code in twitter_http_status_codes:
self.msg = '%s: %s -- %s' % \
(twitter_http_status_codes[error_code][0],
twitter_http_status_codes[error_code][1],
self.msg)
if error_code == 400 or error_code == 420:
raise TwythonAPILimit(self.msg)