On Jun 6, 2016 10:19 AM, "Yury Selivanov" wrote:

...

On Jun 5, 2016, at 11:56 AM, Ben Darnell wrote:

It has come to my attention (

...

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

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. 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).

We’ve discussed this and decided that we should revert asyncio.Timeout

from 3.5.2. I’ll do that later today. This is tangential and somewhat irrelevant given the above, but since I'm not sure where else to put it: having thought about this issue a bit more last night, I also think that it's important that the timeout manager (if/when it's reintroduced) should inject a meaningful exception like TimeoutError, and it should be legal for the coroutine to catch this and continue. This is in contrast to the one that's currently being reverted, which uses the task cancellation feature and is indistinguishable from any other use of the task cancellation feature. -n