classification
Title: Expose ags_gen and agt_gen in asynchronous generators
Type: enhancement Stage: patch review
Components: asyncio Versions: Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Joshua Oreman, ZackerySpytz, asvetlov, dabeaz, giampaolo.rodola, kdart, njs, xgdomingo, yarkot, yselivanov
Priority: normal Keywords: patch

Created on 2018-02-09 19:49 by dabeaz, last changed 2019-02-12 23:29 by Joshua Oreman.

Files
File name Uploaded Description Edit
agen.py dabeaz, 2018-02-10 13:29
Pull Requests
URL Status Linked Edit
PR 11166 open ZackerySpytz, 2018-12-14 19:57
Messages (6)
msg311906 - (view) Author: David Beazley (dabeaz) Date: 2018-02-09 19:49
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.
msg311946 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2018-02-10 09:51
Make sense at first glaze.
msg311950 - (view) Author: David Beazley (dabeaz) Date: 2018-02-10 13:29
I've attached a file that illustrates the issue.

(Side thought: this would be nice to have in inspect or traceback)
msg331860 - (view) Author: Zackery Spytz (ZackerySpytz) * Date: 2018-12-14 19:58
I've created a PR for this issue.
msg331903 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2018-12-15 15:32
Please don't merge the PR. I'll need some time to think about this before giving it a green light.
msg335376 - (view) Author: Joshua Oreman (Joshua Oreman) Date: 2019-02-12 23:29
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?
History
Date User Action Args
2019-02-12 23:29:16Joshua Oremansetnosy: + Joshua Oreman
messages: + msg335376
2018-12-15 15:32:38yselivanovsetmessages: + msg331903
2018-12-14 19:58:26ZackerySpytzsetnosy: + ZackerySpytz

messages: + msg331860
versions: + Python 3.8, - Python 3.7
2018-12-14 19:57:39ZackerySpytzsetkeywords: + patch
stage: patch review
pull_requests: + pull_request10403
2018-09-20 02:45:19kdartsetnosy: + kdart
2018-02-11 02:35:12xgdomingosetnosy: + xgdomingo
2018-02-10 13:29:06dabeazsetfiles: + agen.py

messages: + msg311950
2018-02-10 09:51:35asvetlovsetmessages: + msg311946
2018-02-10 00:35:50pablogsalsetcomponents: + asyncio
2018-02-09 21:52:55njssetnosy: + giampaolo.rodola, njs, asvetlov, yselivanov
2018-02-09 21:17:09yarkotsetnosy: + yarkot
2018-02-09 19:49:33dabeazcreate