feature idea - track internal ratelimiting

[jvanasco]

Has anyone considered tracking ratelimits within Twython, to avoid hitting their API when it will most-likely fail? We have a lot of code that does it externally. I want to avoid network trips that won't work.

[michaelhelmick]

You can use get_application_rate_limit_status to get your applications current rate limit status. You can also except on TwythonRateLimitError or access the rate limiting header (https://github.com/ryanmcgrath/twython/blob/c9026247ee03bc8b22750a87ecf6425094ca77ee/docs/usage/advanced_usage.rst#access-headers-of-previous-call)

[jvanasco]

Let me clarify: we use all those techniques right now to populate a dict associated with the connection, that tracks the ratelimiting for each endpoint.

so a request for a timeline will set in our tracking dict the limit/remaining/reset timers for that endpoint (available via the last headers). before making a call, I check that dict to ensure it's likely to succeed and/or reset the timer. If the request is likely to fail, I raise a ratelimit error. this avoids hitting the server for very-likely failure situations. this also lets us check to see if we have any requests left before hitting the API, so we can cycle in another token if handy.

this is all done outside of twython though... and would likely be better written and maintained if the community at-large were interested in it.