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:
parent
eb22296e33
commit
813626a9ad
2 changed files with 21 additions and 3 deletions
|
|
@ -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)
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue