mike bayer <mike...@zzzcomputing.com> added the comment:
> This recipe was one of the reasons why I added `loop.set_task_factory` > method to the spec, so that it's possible to implement this in an *existing* > event loop like uvloop. But ultimately asyncio is flexible enough to let > users use their own event loop which can be compatible with greenlets among > other improvements. Right, when I sought to look at this, I know that my users want to use the regular event loop in asyncio or whatever system they are using. > Ultimately, asyncio will probably never ship with greenlets integration > enabled by default, but we should definitely make it possible (if there are > some limitations now). It doesn't seem to me that nested event loops are > needed for this, right? So right, the approach I came up with does not need nested event loops and it's my vague understanding that nesting event loops is more difficult to debug, because you have these two separate loops handing off to each other. What is most striking about my recipe is that it never even leaves the default event loop. Originally my first iteration when I was trying to get it working, I had a separate thread going on, as it seemed intuitive that "of course you need a thread to bridge async and sync code" but then I erased the "Thread()" part around it and then it just worked anyway. Like it's simple enough that shipping this as a third party library is almost not even worth it, you can just drop this in wherever. If different libraries had their own drop-in of this, they would even work together. greenlet is really like totally cheating. the philosophical thing here is, usually in my many twitter debates on the subject, folks get into how they like the explicit async and await keywords and they like that IO is explicit. So I'm seeking to keep these people happy and give then "async def execute(sql)", and use an async DB driver, but then the library that these folks are using is internally not actually explicit IO. But they don't have to see that, I've done all the work of the "implicit IO" stuff and in a library it's not the same kind of problem anyway. I think this is a really critical technique to have so that libraries that mediate between a user-facing facade and TCP based backends no longer have to make a hard choice about if they are to support sync vs. async (or async with an optional sync facade around it). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22239> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
