[issue22239] asyncio: nested event loop

Change by Kumar Aditya : -- nosy: +kumaraditya303 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22239] asyncio: nested event loop

Change by Rob Moore : -- nosy: +rob.moore ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22239] asyncio: nested event loop

Douglas Raillard added the comment: Drive by comment: I landed on this thread for the exact same reason: > This situation is very frequent when e.g. a library is designed to be > async-first, and also provides a blocking API which just wraps the async code > by running it until complete.

[issue22239] asyncio: nested event loop

Yury Selivanov added the comment: > nest-asyncio library (https://github.com/erdewit/nest_asyncio) Seeing that the community actively wants to have support for nested loops I'm slowly changing my opinion on this. Guido, maybe we should allow nested asyncio loops disabled by default?

[issue22239] asyncio: nested event loop

David Brochart added the comment: Regarding the initial message in this issue, and enabling recursive event loops, this has proved to be very useful when an event loop is already running and some non-async code needs to run async code. This situation is very frequent when e.g. a library is

[issue22239] asyncio: nested event loop

mike bayer added the comment: I tested "cancellation", shutting down the DB connection mid query. Because the greenlet is only in the middle and not at the endpoints, it propagates the exception and there does not seem to be anything different except for the greenlet sequence in the

[issue22239] asyncio: nested event loop

mike bayer added the comment: as far as cancellation, I gather you're referring to what in gevent / greenlet is the GreenletExit exception. Sure, that thing is a PITA. Hence we're all working to provide asyncio frontends and networking backends so that the effects of cancellation I

[issue22239] asyncio: nested event loop

Change by pmp-p : -- nosy: +pmpp ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22239] asyncio: nested event loop

Nathaniel Smith added the comment: > 90% of everything people are doing here are in the context of HTTP services. > The problem of, "something.a now creates state that other tasks might see" > is not a real "problem" that is solved by using IO-only explicit context > switching. This is

[issue22239] asyncio: nested event loop

mike bayer added the comment: slight correction: it is of course possible to use gevent with a database driver without monkeypatching, as I wrote my own gevent benchmarks using psycogreen. I think what I'm getting at is that it's a good thing if async DBAPIs could target asyncio explicitly

[issue22239] asyncio: nested event loop

mike bayer added the comment: > Oh, I thought the primary problem for SQLAlchemy supporting async is that the > ORM needs to do IO from inside __getattr__ methods. So I assumed that the > reason you were so excited about greenlets was that it would let you use > await_() from inside those

[issue22239] asyncio: nested event loop

Nathaniel Smith added the comment: > Whether or not one buys that, the point of my approach is that SQLAlchemy > itself *will* publish async methods. End user code *will not* ever context > switch to another task without them explicitly calling using an await. Oh, I thought the primary

[issue22239] asyncio: nested event loop

Yury Selivanov added the comment: > The community is hurting *A LOT* right now because asyncio is intentionally > non-compatible with the traditional blocking approach that is not only still > prevalent it's one that a lot of us think is *easier* to work with. Mike, I'm super happy with

[issue22239] asyncio: nested event loop

mike bayer added the comment: > With greenlets OTOH, it becomes possible for another task to observe > someobj.a == 1 without someobj.b == 2, in case someobj.__setattr__ internally > invoked an await_(). let me try this one more time.Basically if someone wrote this: async def

[issue22239] asyncio: nested event loop

mike bayer added the comment: > With greenlets OTOH, it becomes possible for another task to observe > someobj.a == 1 without someobj.b == 2, in case someobj.__setattr__ internally > invoked an await_(). Any operation can potentially invoke a context switch. > So debugging greenlets code is

[issue22239] asyncio: nested event loop

Yury Selivanov added the comment: > Yeah, writing a trivial "event loop" to drive actually-synchronous code is > easy. Try it out: This is exactly the approach I used in edgedb-python. > I guess there's technically some overhead, but it's tiny. Correct, the overhead isn't even detectable

[issue22239] asyncio: nested event loop

Nathaniel Smith added the comment: Yeah, writing a trivial "event loop" to drive actually-synchronous code is easy. Try it out: - async def f(): print("hi from f()") await g() async def g(): print("hi from g()") # This is our event loop: coro = f() try: coro.send(None)

[issue22239] asyncio: nested event loop

Change by Joshua Bronson : -- nosy: +jab ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22239] asyncio: nested event loop

mike bayer added the comment: yes so if you have async/await all internal, are you saying you can make that work for synchronous code *without* running the event loop? that is, some kind of container that just does the right thing? my concern with that would still be performance.When

[issue22239] asyncio: nested event loop

Yury Selivanov added the comment: > 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

[issue22239] asyncio: nested event loop

mike bayer 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

[issue22239] asyncio: nested event loop

Yury Selivanov added the comment: Thanks for posting this, Mike. > Vague claims of "framework X is faster because it's async" appear, impossible > to confirm as it is unknown how much of their performance gains come from the > "async" aspect and how much of it is that they happened to

[issue22239] asyncio: nested event loop

mike bayer added the comment: hey there, I seem to have two cents to offer so here it is.An obscure issue in the Python bug tracker is probably not the right place for this so consider this as an early draft of something that maybe I'll talk about more elsewhere. > This basically

[issue22239] asyncio: nested event loop

Change by Crusader Ky : -- nosy: +Crusader Ky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22239] asyncio: nested event loop

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22239] asyncio: nested event loop

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22239] asyncio: nested event loop

Change by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22239] asyncio: nested event loop

Rokas K. (rku) added the comment: I understand rationale for rejection of this issue but i beg to reconsider. Unlike in traditional coroutines (windows fibers / setjmp|longjmp with stack switching) we can not yield from any point of execution. There must be full async-await chain preserved.

[issue22239] asyncio: nested event loop

Daniel Arbuckle added the comment: All right. However, for anyone who's interested, here is a patch that enables nested event loops in asyncio, and the accompanying unit tests -- keywords: +patch Added file: http://bugs.python.org/file36498/nested.patch

[issue22239] asyncio: nested event loop

Guido van Rossum added the comment: While I understand your problem, I really do not want to enable recursive event loops. While they are popular in some event systems (IIRC libevent relies heavily on the concept), I have heard some strong objections from other parts, and I am trying to keep

[issue22239] asyncio: nested event loop

Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22239 ___ ___ Python-bugs-list

[issue22239] asyncio: nested event loop

New submission from Daniel Arbuckle: It's occasionally necessary to invoke the asyncio event loop from code that was itself invoked within (although usually not directly by) the event loop. For example, imagine you are writing a class that serves as a local proxy for a remote data structure.