On Sun, Nov 12, 2017 at 7:27 AM, Guido van Rossum <gu...@python.org> wrote:
> On Sun, Nov 12, 2017 at 2:53 AM, Chris Jerdonek <chris.jerdo...@gmail.com>
> wrote:
>>
>> By the way, since we're already on the subject of asyncio tasks and
>> (truncated) stack traces, this looks like a good opportunity to ask a
>> question that's been on my mind for a while:
>>
>> There's a mysterious note at the end of the documentation of
>> asyncio.Task's get_stack() method, where it says--
>>
>> > For reasons beyond our control, only one stack frame is returned for a
>> > suspended coroutine.
>>
>> (https://docs.python.org/3/library/asyncio-task.html#asyncio.Task.get_stack
>> )
>>
>> What does the "For reasons beyond our control" mean? What is it that
>> can possibly be beyond the control of Python?
>
>
> It's an odd phrasing, but it refers to the fact that a suspended generator
> frame (which is what a coroutine really is) does not have a "back link" to
> the frame that called it. Whenever a generator yields (or a coroutine
> awaits) its frame is disconnected from the current call stack, control is
> passed to the top frame left on that stack, and the single generator frame
> is just held on to by the generator object. When you call next() on that, it
> will be pushed on top of whatever is the current stack (i.e. whatever calls
> next()), which *may* be a completely different stack configuration than when
> it was suspended.

It is possible to get the await/yield from stack though, even when a
generator/coroutine is suspended, using the gi_yieldfrom / cr_await
attributes. Teaching Task.get_stack to do this would be a nice little
enhancement.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/

Reply via email to