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.

This issue seems to have been closed by accident. There associated PR is still open and there is currently no clean way to access the generator. The workaround using gc.get_referents works though.

cc. @1st1

@erlend-aasland What's going on here? @1st1 is unlikely to react. The PR suddenly gets action. (By you? By the OP?) Maybe you want to reopen this issue? (The last comment suggests it should be reopened.)

@gvanrossum: I did an audit of all open issues and PRs by @ZackerySpytz earlier today. The linked PR (#11166, authored by Zackery) was still open, and this issue seemed to have been closed by accident, hence the ping.

Yeah, @1st1 really won't look at this, so we need someone else to do so. I'll reopen it so at least it's clear that this was closed by mistake.

I'm closing this. Six years ago @1st1 didn't like the idea of exposing these implementation details, and not too many people have requested this feature since then.