Added monitoring of api rate limits and waiting for replenishment.

[nirg]

Should address issue #254.

[Aaron1011]

@joshthecoder: Does this look good to you?

[joshthecoder]

Not sure I like sleeping until the rate limit is removed. Almost would prefer just an exception
with the x-rate-limit header information included.

[nirg]

Waiting is conditional on an optional parameter, which is set by default to
false, and an exception raised in that case (without the rate limit info).
However, for applications that use cursors an exception would not make
sense because the application would have to repeat some calls that the
cursor already made. Unless we start doing exception handling at the cursor
level, I don't think that throwing an exception is the best choice here.
Now, since cursor usage is most the common use case that leads to rate
limits I think waiting on the api call level makes most sense. What do you
suggest otherwise?

On Feb 26, 2014 11:35 AM, "Joshua Roesslein" [email protected]
wrote:

Not sure I like sleeping until the rate limit is removed. Almost would
prefer just an exception
with the x-rate-limit header information included.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/390#issuecomment-36145351
.

[Aaron1011]

@nirg: Shouldn't we always store the remaining calls and time until reset? Even if Tweepy doesn't sleep, it might be useful to be able to get the number of calls remaining?

[nirg]

Well, I don't mind doing it either way, but I think the more likely use
cases to reach the rate limits are ones that use cursors and in these cases
it makes sense to wait or get an exception. If you come up with a use case
that needs to monitor the rate limit and doesn't involve a cursor then I'm
happy to implement it.
On Mar 13, 2014 2:56 PM, "Aaron1011" [email protected] wrote:

In tweepy/binder.py:

@@ -155,15 +167,31 @@ def execute(self):
resp = conn.getresponse()
except Exception, e:

raise TweepError('Failed to send request: %s' % e)

•            if self.wait_on_rate_limit:
  

@nirg https://github.com/nirg: Shouldn't we always store the remaining
calls and time until reset? Even if Tweepy doesn't sleep, it might be
useful to be able to get the number of calls remaining?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/390/files#r10580177
.