[Patches] [ python-Patches-643835 ] Set Next Statement for Python debuggers
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 11 Dec 2002 00:54:46 -0800
Patches item #643835, was opened at 2002-11-25 23:18
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=643835&group_id=5470
Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richie Hindle (richiehindle)
Assigned to: Michael Hudson (mwh)
Summary: Set Next Statement for Python debuggers
Initial Comment:
"Set Next Statement", aka "Jump", for Python debuggers.
For Python 2.3a0 on all platforms (built and tested in Win98).
This patch adds the ability for Python debuggers (including
pdb) to control which line of code in a frame will be executed
next. This allows the user to jump back and execute code
again, or jump forward to skip code that he doesn't want to
run. A debugger (or anything else that installs a trace
function) does this by setting the value of frame.f_lineno
from within a trace function.
There are some situations where you can't jump because it
would break the stack - these are caught and a ValueError
is raised.
There are other cases where the jump *is* possible but the
stack needs fixing up, and the code does that.
The patch includes:
o A setter for frame.f_lineno, in frameobject.c
o A new command 'j(ump) <line number>' for pdb.
o Tests in test_trace.py for all the allowed and disallowed
types of jumps.
o Updated documentation for pdb and frame objects.
----------------------------------------------------------------------
>Comment By: Richie Hindle (richiehindle)
Date: 2002-12-11 08:54
Message:
Logged In: YES
user_id=85414
Sorry to need prodding! I agree with pretty much everything
you said. I was planning to just make the edits and submit
a new patch, but real life has got in the way.
I'll come up with a fresh patch soon. The only thing that
wasn't clear was "Restricted mode!?" Does this mean that
the code should behave differently in restricted mode
(probably it should fail with an explanatory exception).
Do you know off the top of your head how my C code
can find out whether it's in restricted mode?
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-12-10 17:56
Message:
Logged In: YES
user_id=6656
<prod>
Do you have comments on my comments? I can implement most
of my suggestions myself, but I thought it would be quicker
for you to do them...
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-12-06 15:35
Message:
Logged In: YES
user_id=6656
This is what happens when I download a patch and take it
home for comments:
Meta: Impressed! This is a bit long, so I suggest composing
your
reply in your mailer and pasting the result into the browser...
---------------------------------------------------
I get a couple of char** vs unsigned char** pointer
warnings. Trivial
stuff.
---------------------------------------------------
what should this:
def f(): # call this line 1
print 1, # 2
g() # 3
print 2, # 4
print 3 # 5
def g():
sys._getframe().f_back.f_lineno = 5
do? Three options:
1) barf
2) "work", i.e. print 1, 3
3) "fail silently", i.e. print 1, 2, 3
I think 1) is ideal. The patch gives 3). Could get slight
protection
by complaining in frame_setlineno if f_trace is not set.
OTOH, not
going to lose any sleep over this. The documentation should
be clear
on this, though.
Also unclear what to expect if you execute eg. "up" followed
by "j 10"
in pdb. Perhaps should complain?
---------------------------------------------------
Restricted mode!?
---------------------------------------------------
I'm not *convinced* that except: lines are the only ones
that start
with POP_TOP. OTOH:
1) it's not that significant if they're not
2) when I went looking for counter-examples in compile.c I found
somewhere that looked as if a POP_TOP could start the
line, went
"ooh!" and then noticed that it was compiling an except:
line :-)
---------------------------------------------------
Mondo fragile. What happens if a bus hits Richie?
Maybe add pseudo Python? E.g. how would the jump into/out
of finally
block detection look written using the bytecodehacks?
---------------------------------------------------
*Like* the testing framework. Very neat.
Could split the jump tests out into a new test case.
line 264 of test_trace: why x = 1, not output.append(4)?
Don't test the "must be an integer" part...
Perhaps should test all except line variants:
except:
except ClassName:
except ClassName, var:
(to make sure test fails if compilation details change).
Doesn't test a jump within a finally block.
Faintly worried about silly things like nested finally blocks.
Would like to see a test like this:
def mwh_nested_finally(output):
try:
output.append(2)
finally:
output.append(4)
try:
output.append(6)
finally:
output.append(8)
output.append(9)
mwh_nested_finally.jump = (4, 9)
mwh_nested_finally.output = [2, 9]
(which passes, but that's not the point)
---------------------------------------------------
For checkin:
1) clarify docs
2) add bytecodehacks-stylee code in comments
3) split out into separate test case
4) add a couple tests (all except styles, nested finallys).
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-26 13:44
Message:
Logged In: YES
user_id=6380
Yes, please review! The idea is cool, and it sounds like
he's thought about the consequences (I hope he also checks
the block stack).
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-11-26 10:59
Message:
Logged In: YES
user_id=6656
Er, wow :)
Guido, do you approve of the idea? If so, assign to me and
I'll review & test it.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=643835&group_id=5470