[Python-Dev] Python advanced debug support (update frame code)

Nick Coghlan ncoghlan at gmail.com
Mon Jan 13 14:43:35 CET 2014


On 13 January 2014 09:08, Fabio Zadrozny <fabiofz at gmail.com> wrote:
> Hi Python-dev.
>
> I'm playing a bit on the concept on live-coding during a debug session and
> one of the most annoying things is that although I can reload the code for a
> function (using something close to xreload), it seems it's not possible to
> change the code for the current frame (i.e.: I need to get out of the
> function call and then back in to a call to the method from that frame to
> see the changes).
>
> I gave a look on the frameobject and it seems it would be possible to set
> frame.f_code to another code object -- and set the line number to the start
> of the new object, which would cover the most common situation, which would
> be restarting the current frame -- provided the arguments remain the same
> (which is close to what the java debugger in Eclipse does when it drops the
> current frame -- on Python, provided I'm not in a try..except block I can do
> even better setting the the frame.f_lineno, but without being able to change
> the frame f_code it loses a lot of its usefulness).
>
> So, I'd like to ask for feedback from people with more knowledge on whether
> it'd be actually feasible to change the frame.f_code and possible
> implications on doing that.

Huh, I would have sworn there was already an issue on the tracker
about that, but it appears not (Eric Snow has one about adding a
reference to the running function, but nothing about trying to switch
an executing frame: http://bugs.python.org/issue12857).

Anyway, your main problem isn't the reference to the code object from
the frame: it's the fact that the main eval loop has a reference to
that code object from a C level stack variable, and stores a bunch of
other state directly on the C stack.

I don't see anything *intrinsically* impossible about the idea, it
just wouldn't be easy, since you'd have to come up with a way of
dealing with that C level state that didn't slow down normal
operation.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list