Best way forward with regards to native coroutines

[PatTheMav]

I'd just appreciate to hear your opinion on this, as I'm planning to update my Tornado app for async/await (and looking forward to Tornado 5):

Would a fork of tornadis for Python 3.5+ using native coroutines be the best move forward (especially regarding the gotchas mentioned in the official Tornado docs - I'm not aware how much tornadis relies on some of that functionality)?

Or is this something that this project will tackle down the line?

[PatTheMav]

FYI - I'm currently migrating my web app to Python 3.5 and async/await - so far most functionality works as intended (as Tornado "marks" generated coroutines for native usage) with the exception of the ContextManagerFuture which doesn't seem to work (and leads to blocking the whole application when used with await) - probably requires an asynchronous context manager as as defined in PEP-492.

[thefab]

Hi,

Sorry for the reply delay. I don't know a lot about native coroutines because I can't work on python >= 3.5 only.

I think that a fork will be better at this time.

If you are interested, I can add a link to your fork in the REAME for people interested in native coroutines.

Regards

[PatTheMav]

Hey @thefab,

Thanks for your reply - alas I'm not really well suited to be the one writing or even maintaining a fork at this moment (writing software is more of a guilty pleasure for me).

As I've mentioned in my second comment tornadis is working with native coroutines without issue as long as no context manager patterns are used (the tornado generators take care of making the coroutines compatible with each other) and the only benefit would be a considerable speed improvement (especially given Tornado 5.0's move to asyncio instead of its own ioloop).

But I agree that such a fork or (backward-compatibility breaking) major release might be necessary to reap the performance benefits asyncio and native coroutines bring.