[issue12857] Expose called function on frame object

Change by Zachary Ware : -- Removed message: https://bugs.python.org/msg345592 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue12857] Expose called function on frame object

Change by Eric Snow : Removed file: https://bugs.python.org/file48418/122.pdf ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue12857] Expose called function on frame object

kev levrone added the comment: def enable_ki_protection(func): func._trio_keyboard_interrupt_protection_enabled = True return func -- nosy: +kevlevrone Added file: https://bugs.python.org/file48418/122.pdf ___ Python tracker

[issue12857] Expose called function on frame object

Changes by Jakub Stasiak : -- nosy: +jstasiak ___ Python tracker ___ ___

[issue12857] Expose called function on frame object

Nick Coghlan added the comment: Regarding Mark's point about the anonymous scopes created for things like list comprehensions, at least in CPython, those are actually full functions with generated names like "" (at module level) or "f.." (at function level). >From the point of view of code

[issue12857] Expose called function on frame object

Nathaniel Smith added the comment: > Yes, whenever you touch frames you're disabling the JIT for the call site > (and maybe for more call sites up the stack, idk). So it doesn't matter what > you use, `f_func` or `f_locals`, the performance will suffer big time. Is > that acceptable for

[issue12857] Expose called function on frame object

Yury Selivanov added the comment: > Sure. The issue is that I need to mark certain frames as "protected" from > KeyboardInterrupt, in a way that my signal handler can see when walking the > frame stack, so it can decide whether to raise a KeyboardInterrupt > immediately or to wait until a

[issue12857] Expose called function on frame object

Nathaniel Smith added the comment: > I'm not sure I understand how `f_func` would help to better handle Control-C > in Trio. Nathaniel, could you please elaborate on that? Sure. The issue is that I need to mark certain frames as "protected" from KeyboardInterrupt, in a way that my signal

[issue12857] Expose called function on frame object

Yury Selivanov added the comment: > I don't see a better way to handle my (admittedly a bit weird) control-C case > within the interpreter I'm not sure I understand how `f_func` would help to better handle Control-C in Trio. Nathaniel, could you please elaborate on that? --

[issue12857] Expose called function on frame object

Nathaniel Smith added the comment: Certainly which frame is being executed is an implementation detail, and I can see an argument from that that we shouldn't have a frame introspection API at all... but we do have one, and it has some pretty important use cases, like traceback printing.

[issue12857] Expose called function on frame object

Mark Shannon added the comment: I'm not too keen on this. Which frame is being executed is an implementation detail. For example, we currently push a new frame for list comprehensions, but that is an implementation detail. The language only specifies that list-comps execute in a new scope.

[issue12857] Expose called function on frame object

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

[issue12857] Expose called function on frame object

Changes by Jim Fasarakis-Hilliard : -- nosy: +Jim Fasarakis-Hilliard ___ Python tracker ___

[issue12857] Expose called function on frame object

Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___

[issue12857] Expose called function on frame object

Nick Coghlan added the comment: This topic came up in a discussion I was having with Yury, and thanks to generators and coroutines, I don't think "f_func" would be the right name for an attribute like this, with something more neutral like "f_origin" potentially being preferable The specific

[issue12857] Expose called function on frame object

Mark Lawrence added the comment: Note that #13672 referred to in msg156962 refers to #13855. -- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12857

[issue12857] Expose called function on frame object

Changes by Eric Snow ericsnowcurren...@gmail.com: -- assignee: - eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12857 ___ ___

[issue12857] Expose called function on frame object

Eric Snow ericsnowcurren...@gmail.com added the comment: It's been a while and I probably need to clean up that last patch a little. I also need to address the questions of: 1. f_func for class/module execution 2. thread-safety see:

[issue12857] Expose called function on frame object

Eric Snow ericsnowcurren...@gmail.com added the comment: for reference, a related issue: http://bugs.python.org/issue13672 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12857 ___

[issue12857] Expose called function on frame object

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12857 ___

[issue12857] Expose called function on frame object

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12857 ___ ___ Python-bugs-list mailing list

[issue12857] Expose called function on frame object

Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12857 ___ ___ Python-bugs-list

[issue12857] Expose called function on frame object

Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12857 ___ ___ Python-bugs-list

[issue12857] Expose called function on frame object

Benjamin Peterson benja...@python.org added the comment: What would you use the functionality provided by this patch for? -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12857

[issue12857] Expose called function on frame object

Eric Snow ericsnowcurren...@gmail.com added the comment: My response to a similar query: What it enables is the ability to introspect the *actual* function object belonging to the currently executing code, whether in the same execution frame or in a later one on the stack. We don't have that

[issue12857] Expose called function on frame object

Eric Snow ericsnowcurren...@gmail.com added the comment: Nick, does thing look better? -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12857 ___

[issue12857] Expose called function on frame object

Eric Snow ericsnowcurren...@gmail.com added the comment: Finally had a chance to get back to this. Here's a new patch in response to Nick's review. My only concern is the new _PyEval_EvalFunctionCode function. It is basically the existing PyEval_EvalCodeEx function with an extra parameter.

[issue12857] Expose called function on frame object

Changes by Daniel Urban urban.dani...@gmail.com: -- nosy: +durban ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12857 ___ ___ Python-bugs-list

[issue12857] Expose called function on frame object

Eric Snow ericsnowcurren...@gmail.com added the comment: Thanks for the review, Nick. I'll be uploading a new patch in a couple hours with your recommended fixes. Regarding the comments on python-ideas, would it be better to use a weakref proxy around the function, to help with the reference

[issue12857] Expose called function on frame object

Eric Snow ericsnowcurren...@gmail.com added the comment: On second thought, I probably won't be able to get an updated patch tonight. I need to mull over the PyEval_EvalFunction implementation and the interaction with fast_function. -- ___ Python

[issue12857] Expose called function on frame object

New submission from Eric Snow ericsnowcurren...@gmail.com: This patch adds f_func to PyFrameObject and sets it for functions that get called (in PyFrame_New). For classes and modules it is set to None. The difference in performance was not noticable, as far as I could tell. However, I am