>>>> try:
>>>> return await waiter
>>>> finally:
>>>> # TODO: Use a context manager to add and remove the keys.
>>>> for key in keys:
>>>> self._waiters[key].discard(waiter)
>>>> if handle:
>>>> handle.cancel()
>>>>
>>>> def notify(self, key, message):
>>>> if key in self._waiters and self._waiters[key]:
>>>> waiter = next(iter(self._waiters[key]))
>>>> waiter.set_result((key, message))
>>> I think this is what I needed. I'm going to try this tomorrow.
>> Yes, putting aside the asyncio/tornado distinction, I think a Future
>> will still solve the problem for you.
> No, it won't. :-(
>
> Finally, I got it working, by replacing asyncio.Future with
> tornado.concurrent.Future.
>
> At least it is consistent. But it is also missing key features. For
> example, there is no tornado.concurrent.Condition.
I was corrected, as follows:
> asyncio.Futures depend on the asyncio event loop, so you must
> configure Tornado to use the asyncio loop:
>
>
> tornado.ioloop.IOLoop.configure('tornado.platform.asyncio.AsyncIOMainLoop')
>
> This could definitely use some better documentation. It would be nice
> if it could fail in a more graceful way (give an error message instead
> of hanging), but I'm not sure if there's any way to do that.
>
So tornado can be used with asyncio, but it requires configuration (and
it is not yet very well documented).
> Also, for your python-list message: there is now (since 4.2) a Tornado
> Condition class, but it lives in tornado.locks instead of
> tornado.concurrent.
There is a little incosistency here, but at least there is a Condition
class.
I think the tornado team is trying to make tornado fully compatible with
asyncio, just the are not there yet.
--
https://mail.python.org/mailman/listinfo/python-list
