<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 13, 2015 at 9:21 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13 June 2015 at 20:25, Ben Leslie <<a href="mailto:benno@benno.id.au">benno@benno.id.au</a>> wrote:<br>
> Is there any reason an f_stack attribute is not exposed for frames? Many of the<br>
> other PyFrameObject values are exposed. I'm guessing that there probably<br>
> aren't too many places where you can get hold of a frame that doesn't have an<br>
> empty stack in normal operation, so it probably isn't necessary.<br>
<br>
</span>There's also the fact that anything we do in CPython that assumes a<br>
value stack based interpreter implementation might not work on other<br>
Python implementations, so we generally try to keep that level of<br>
detail hidden.<br>
<span class=""><br>
> Anyway, I'm not suggesting that adding f_stack is better than explicitly<br>
> adding pointers, but it does seem a more general thing that can be exposed<br>
> and enable this use case without requiring extra book-keeping data structures.<br>
<br>
</span>Emulating CPython frames on other implementations is already hard<br>
enough, without exposing the value stack directly.<br></blockquote><div><br></div><div>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).<br><br>But I agree it isn't a solution to the question about the suspension "stack".<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Compared to "emulate CPython's value stack", "keep track of delegation<br>
to subiterators and subcoroutines" is a far more reasonable request to<br>
make of developers of other implementations.<br>
<br>
>From a learnability perspective, there's also nothing about an<br>
"f_stack" attribute that says "you can use this to find out where a<br>
generator or coroutine has delegated control", while attributes like<br>
"gi_delegate" or "cr_delegate" would be more self-explanatory.<br clear="all"></blockquote><div><br></div><div>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.<br></div></div><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>