Why is the code for handling rate-limiting a loop?

[Samathingamajig]

Why is the code for handling rate-limiting a loop?

https://github.com/Teekeks/pyTwitchAPI/blob/fb958562eadf99e3c22d86cd81edae55d896c275/twitchAPI/twitch.py#L288-L293

I think it would be the same if it was something like

        if response.status_code == 429 or str(response.headers.get('Ratelimit-Remaining', '')) == '0':
            self.__logger.warning('reached rate limit, waiting for reset')
            import time
            reset = int(response.headers['Ratelimit-Reset'])
            time.sleep(reset - time.time()) # time.time() returns `<class 'float'>`

also shouldn't time be imported at the top of the file?

The only reason I can think of the original implementation being done is either because this is an optimization for telling the interpreter it can focus on async code, or it wants to be completely sure to go past the reset time. (still no clue why import time is inside the if block and not imported at the top of the file)

[Samathingamajig]

Also while we're here, is everything in this library synchronous? If it is that could cause issues when using a webserver (e.g. Flask)

[chillymosh]

Flask is a sync webserver FYI. Quart is the async version of Flask along with aiohttp etc.

[Teekeks]

1) time.sleep is blocking, this way to implement it assures that a async event loop in the same thread can still run while we are waiting for a timeout.

2) time is only imported there as a optimization since running into the rate limits is rather rare for most usecases of the library.

3) I am planning on offering both a sync (the current version) as well as a async version of the api calls in the future. They are currently sync since that was the requirements for a project when I started writing this library years ago.