This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Arfrever, BreamoreBoy, benjamin.peterson, cvrebert, daniel.urban, eric.snow, jcea, meador.inge, ncoghlan, yselivanov
Date 2016-11-01.01:29:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1477963760.16.0.487006319057.issue12857@psf.upfronthosting.co.za>
In-reply-to
Content
This topic came up in a discussion I was having with Yury, and thanks to generators and coroutines, I don't think "f_func" would be the right name for an attribute like this, with something more neutral like "f_origin" potentially being preferable

The specific runtime debugging use case I have in mind is this:

1. Given a frame reference, navigate to the generator-iterator or coroutine that spawned that frame
2. Given gi_back and cr_back doubly-linked counterparts to the current gi_yieldfrom and cr_await introspection attributes on generators and coroutines, expose the relevant generator and/or coroutine stack in addition to the frame stack

These secondary stacks could then potentially be incorporated into traceback outputs by default
History
Date User Action Args
2016-11-01 01:29:20ncoghlansetrecipients: + ncoghlan, jcea, benjamin.peterson, Arfrever, cvrebert, meador.inge, daniel.urban, BreamoreBoy, eric.snow, yselivanov
2016-11-01 01:29:20ncoghlansetmessageid: <1477963760.16.0.487006319057.issue12857@psf.upfronthosting.co.za>
2016-11-01 01:29:20ncoghlanlinkissue12857 messages
2016-11-01 01:29:18ncoghlancreate