Nathaniel Smith added the comment:

I'd also like to make use of this in trio, as a way to get safer and less 
complicated control-C handling without having to implement things in C. 
(Exhaustive discussion: 
https://vorpus.org/blog/control-c-handling-in-python-and-trio/)

@Nick: I understand your proposal is to add a field on the frame that for 
regular function calls points to the function object, and for 
generator/coroutines points to the generator/coroutine object. Is that right? 
Two possible concerns there: (a) this creates a reference cycle, because 
generator/coroutine objects own a reference to the frame object, (b) AFAICT you 
also currently can't get from a generator/coroutine object back to the function 
object, so this would break some (all?) of the use cases for this. I guess the 
solution to (a) is to make it a weak reference, and for (b) either keep f_func 
as always pointing to the function and make f_generator a separate field, or 
else make it f_origin and also add gi_func/co_func fields to 
generator/coroutine objects. (Which might be useful in any case.)

Also, I'm not quite following the proposed use case. When a generator/coroutine 
is resumed, then send() steps through the whole yield stack and reconstructs 
the frame stack so it matches the generator/coroutine stack. (throw() currently 
doesn't do this, but that's a bug that breaks profilers/debuggers/etc - 
bpo-29590 - so we should fix it anyway, and I think Yury is planning to do that 
soon.) So if you get a frame from sys._getframe() or similar, then the stack is 
correct. And if a coroutine/generator isn't running, then the only way to get 
to the frame is by starting with the coroutine/generator object, so we don't 
really need a way to get back.

Tracebacks are a different case again because they continue to hold frame 
references after the stack is unwound, but generally the traceback already has 
the correct stack because the exception propagates up the coroutine/generator 
stack, and also aren't the {gi,co}_frame references cleared as the exception 
propagates anyway?

----------
nosy: +njs

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12857>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to