Libraries such as Curio and asyncio provide a debugging facility that allows someone to view the call stack of generators/coroutines.  For example, the _task_get_stack() function in asyncio/base_tasks.py.  This works by manually walking up the chain of coroutines (by following cr_frame and gi_frame links as appropriate).   

The only problem is that it doesn't work if control flow falls into an async generator because an "async_generator_asend" instance is encountered and there is no meaningful way to proceed any further with stack inspection.

This problem could be fixed if "async_generator_asend" and "async_generator_athrow" instances exposed the underlying "ags_gen" and "agt_gen" attribute that's held inside the corresponding C structures in Objects/genobject.c.  

Note: I made a quick and dirty "hack" to Python to extract "ags_gen" and verified that having this information would allow me to get complete stack traces in Curio.

Make sense at first glaze.

I've attached a file that illustrates the issue.

(Side thought: this would be nice to have in inspect or traceback)

I've created a PR for this issue.

Please don't merge the PR. I'll need some time to think about this before giving it a green light.

I also ran into this. My workaround was to use gc.get_referents() on the async_generator_asend object, which returns a one-element list containing the async generator object. I don't know if this is guaranteed or just happened to work in the cases I was using it, but it might be good enough?

Also, while the PEP first introducing asynchronous generators stated that its .asend() and .athrow() methods will return a "coroutine-like object", it doesn't allow any introspection into its state or parent async generator.

My workaround was to wrap the .asend() and other methods with another coroutine that just awaits and returns the result. Having a better way to check its state and frame will bring it closer to a coroutine.

messages: + msg331860
versions: + Python 3.8, - Python 3.7

messages: + msg311950