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 <[email protected]>
<http://bugs.python.org/issue12857>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
