pdb next command forces you to step over each list element.

This seem to be a reincarnation of this old bug.
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470

Version:
Python 2.4.1 (#2, Mar 30 2005, 21:51:10) 
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2

Logged In: YES 
user_id=971153


I changed bdb.py to print the kind of event it receives as
well as as line numbers and here is a session which
illustrates the bug...

 bagira:~/python/dist/src/bug-next1248119> cat t
 #../python
 y=[1,2,3,4]
 x=[ i+1 for i in y]
 print x
 bagira:~/python/dist/src/bug-next1248119> ../python -m pdb t
 event: call; line 1, file <string>
 event: line; line 1, file <string>
 event: call; line 2, file t
 event: line; line 2, file t
 > /home/ilya/python/dist/src/bug-next1248119/t(2)?()
 -> y=[1,2,3,4]
 (Pdb) n
 event: line; line 3, file t
 > /home/ilya/python/dist/src/bug-next1248119/t(3)?()
 -> x=[ i+1 for i in y]
 (Pdb) n
 event: line; line 3, file t
 > /home/ilya/python/dist/src/bug-next1248119/t(3)?()
 -> x=[ i+1 for i in y]
 (Pdb) n
 event: line; line 3, file t
 > /home/ilya/python/dist/src/bug-next1248119/t(3)?()
 -> x=[ i+1 for i in y]
 (Pdb) 
 event: line; line 3, file t
 > /home/ilya/python/dist/src/bug-next1248119/t(3)?()
 -> x=[ i+1 for i in y]

So it appears that the interpreter generates "line" events
for every iteration of the loop..

Would this be a bug in the interpreter (and not in pdb/bdb)?

Logged In: YES 
user_id=971153


A bit more information. I looked into what happens in
ceval.c and apparently the current behaviour is intentional..

Looks like this piece of code:

	else if (frame->f_lasti <= *instr_prev) {
		/* jumping back in the same line forces a trace event */
		result = call_trace(func, obj, frame,
				    PyTrace_LINE, Py_None);
	}

in maybe_call_line_trace() is responsible for the extra
"line" events..
Seems like this piece of code was added to fix bug #765624.
in ceval.c:2.386

So, should this (1248119) bug be dealt with by skipping
extra line events in bdb?

Any thoughts? Or am I totally lost?

Logged In: YES 
user_id=971153

While this behaviour indeed feels like a bug I'm starting to
think that it is not..

Observation1: 'step' should stop at every iteration of a
list comprehension

Observation2: the only difference between 'step' and 'next'
 is that 'step' steps into function calls (which is not the
case here)

So, it seems like 'next' should also stop at every iteration
of a list comprehenstion. Ie current behaviour is not a bug...

Would supporting a numeric argument for the 'next' command
make sense? 

So that 'next 1' would mean "stop when actual line number
increases by at least 1"...

Logged In: YES 
user_id=86677


You probably never use pdb in a real program, otherwise you
would realize what a serious bummer this is. 

Giving a 'next N' is nice, but will not be a real solution.
Somethims it is not easy to know how many iterations there
are. And when they are nested etc.

If you are convinced this is the desired and reasonable
behaviour for next (a point of view I don't share), at least
have a different command to skip to the next line. I am
sorry but I have no idea if this is easy or hard.

Thanks, Joseph

Logged In: YES 
user_id=971153

> you would realize what a serious bummer this is. 

I agree: this is a definite inconvenience. But I don't see
how it is different from having to step through any other
loop. However, I think there is a way to solve both problems
at once..See below

> Giving a 'next N' is nice, but will not be a real solution.
> Somethims it is not easy to know how many iterations there
> are. And when they are nested etc.

Actually, I did not mean "next N" to skip N iterations, what
I meant
to have 'next N' (or at least next 1) to skip next N lines
of code.
I.e stop only when
   line>=line_where_next_N_happened+N 
is reached...

So it seems like we are talking about the same thing...Right?

There are a couple of corner cases which would have to be
handled, (e.g keeping track of the current frame, etc)
 
Also "next N" would allow to easily skip over any loops (not
just list comprehensions), which I think would be a useful
feature...

What do you think?

Logged In: YES 
user_id=86677

I think this will be wonderfull ....

The only viable workaround now is to wrap the code in a
temporary function (i.e. lambda : ...). ugly.

-Thanks, JOseph

Logged In: YES 
user_id=971153

 > The only viable workaround now is to wrap the code in a 
 > temporary function (i.e. lambda : ...). ugly.

Would setting a temporary breakpoint  (tbreak) on the line
after list comprehension be a much simpler workaround?

Logged In: YES 
user_id=971153

I raised this question on python-dev. There was only a
couple of replies.

To summarize: the original "next N" suggestion got -1 
(b/c in gdb "next N" means repeat "next" N times and it is
desirable to keep pdb's and gdb's command sets as close as
possible), however the alternative suggestion to implement
"until" (which is also supported by gdb)  got +1.

Python-dev reference:
http://mail.python.org/pipermail/python-dev/2005-August/055298.html

Patch  #1267629  implements 'until' and should address the
original problem.

Will close this one as fixed by issue 1267629, unless someone voices
disagreement.

Let's do it.