It looks like the TwitterError type is inconsistent in what can be in the message. For example, if it's an error returned by the API its message will be a list, e.g. [{'code': 34, 'message': 'Sorry, that page does not exist.'}], but in some other cases it can be a dict, e.g. {'Unknown error': ''}. I've also seen a few occurrences in the code of strings being set as the error's message.
This makes error handling tricky, and also makes it very likely that an app using this library without knowing about this undocumented subtlety will unexpectedly crash when the app is deployed in production (which happened to me the other day).
I'd suggest splitting this error class into separate classes, one for each format, e.g. make it TwitterApiError when the error comes from the API response.
It looks like the
TwitterErrortype is inconsistent in what can be in the message. For example, if it's an error returned by the API its message will be a list, e.g.[{'code': 34, 'message': 'Sorry, that page does not exist.'}], but in some other cases it can be a dict, e.g.{'Unknown error': ''}. I've also seen a few occurrences in the code of strings being set as the error's message.This makes error handling tricky, and also makes it very likely that an app using this library without knowing about this undocumented subtlety will unexpectedly crash when the app is deployed in production (which happened to me the other day).
I'd suggest splitting this error class into separate classes, one for each format, e.g. make it
TwitterApiErrorwhen the error comes from the API response.