You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In applications that deal with RESTful web APIs I frequently come across situations where the code looks like the folowing.
API call to get number of "items" available
Loop over a series of API calls to get those "items" in batches
The problem is that if I use a progress bar to track progress, naïve code suffers from a race condition if the number of "things" available changes between the call to get their count and the calls to fetch them.
This results in a lot of repetitious boilerplate code along the lines:
if count <= max_value:
bar.update(count)
It's easy to forget to include the guard, which results in annoying non-deterministic failures that are hard to catch in testing.
It would be nice if the library could (optionally) include logic to ignore updates outside the expected range.
In applications that deal with RESTful web APIs I frequently come across situations where the code looks like the folowing.
The problem is that if I use a progress bar to track progress, naïve code suffers from a race condition if the number of "things" available changes between the call to get their count and the calls to fetch them.
This results in a lot of repetitious boilerplate code along the lines:
It's easy to forget to include the guard, which results in annoying non-deterministic failures that are hard to catch in testing.
It would be nice if the library could (optionally) include logic to ignore updates outside the expected range.