[Python-Dev] Obtaining stack-frames from co-routine objects

[Guido van Rossum]

On Sat, Jun 13, 2015 at 9:21 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 13 June 2015 at 20:25, Ben Leslie <benno at benno.id.au> wrote:
> > Is there any reason an f_stack attribute is not exposed for frames? Many
> of the
> > other PyFrameObject values are exposed. I'm guessing that there probably
> > aren't too many places where you can get hold of a frame that doesn't
> have an
> > empty stack in normal operation, so it probably isn't necessary.
>
> There's also the fact that anything we do in CPython that assumes a
> value stack based interpreter implementation might not work on other
> Python implementations, so we generally try to keep that level of
> detail hidden.
>
> > Anyway, I'm not suggesting that adding f_stack is better than explicitly
> > adding pointers, but it does seem a more general thing that can be
> exposed
> > and enable this use case without requiring extra book-keeping data
> structures.
>
> Emulating CPython frames on other implementations is already hard
> enough, without exposing the value stack directly.
>

I'm not sure how strong this argument is. We also expose bytecode, which is
about as unportable as anything. (Though arguably we can't keep bytecode a
secret, because it's written to .pyc files.) I find Ben's implementation
pretty straightforward, and because it makes a copy, I don't think there's
anything one could do with the exposed stack that could violate any of the
interpreter's invariants (I might change it to return a tuple to emphasize
this point to the caller though).

But I agree it isn't a solution to the question about the suspension
"stack".


> Compared to "emulate CPython's value stack", "keep track of delegation
> to subiterators and subcoroutines" is a far more reasonable request to
> make of developers of other implementations.
>
> From a learnability perspective, there's also nothing about an
> "f_stack" attribute that says "you can use this to find out where a
> generator or coroutine has delegated control", while attributes like
> "gi_delegate" or "cr_delegate" would be more self-explanatory.
>

Stack frame objects are kind of expensive and I would hate to add an extra
pointer to every frame just to support this functionality. Perhaps we could
have a flag though that says whether the top of the stack is in fact the
generator object on which we're waiting in a yield-from? This flag could
perhaps sit next to f_executing (also note that this new flag is mutually
exclusive with f_executing). We could then easily provide a new method or
property on the frame object that returns the desired generator if the flag
is set or None if the flag is not set -- other Python implementations could
choose to implement this differently.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150613/2bd9943a/attachment.html>