Home Original page

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

Nick Coghlan ncoghlan at gmail.com
Sat Jun 13 18:21:55 CEST 2015 
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.

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
More information about the Python-Dev mailing list