On Jun 5, 2016 8:57 AM, "Ben Darnell" <ben@bendarnell.com> wrote:
It has come to my attention (
https://github.com/KeepSafe/aiohttp/issues/877) that Python 3.5.2 (!) introduced a new context manager asyncio.timeout, which attaches a timeout to the current asyncio.Task. Any library or application that uses this feature will not be portable to other coroutine runners.
with asyncio.timeout(1): result = await aiohttp.get('http://www.example.com')
It's difficult to make this interface portable. We'd need to introduce a
global thread-specific object that all of the coroutine runners could register the current task on, and define an interface that asyncio.timeout would call on that object to set the timeout. We could get rid of the global if the context manager used `async with` instead of `with`, since that would give us a way to communicate with the coroutine runner directly, but the net result is still that each runner needs to implement hooks for this feature (the hooks may or may not be generalizable to other features in the future). Right -- fwiw curio's version of this uses either 'async with' (like you suggest) or acts as a wrapper (like tornado): http://curio.readthedocs.io/en/latest/reference.html#timeouts But this is consistent with these library's respective conventions: asyncio's style in general is to look up the event loop using global state that has to be kept synchronized, and here that's extended to looking up the current coroutine runner as well. Curio, OTOH, never manipulates global state. So to me this points to one of the fundamental differences between these approaches; it doesn't seem like something where one can just look at the timeout function in isolation. -n