Issue1248119
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2005-07-30 21:12 by pepster, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (11) | |||
---|---|---|---|
msg60787 - (view) | Author: Joseph Heled (pepster) | Date: 2005-07-30 21:12 | |
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 |
|||
msg60788 - (view) | Author: Ilya Sandler (isandler) | Date: 2005-07-31 00:33 | |
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)? |
|||
msg60789 - (view) | Author: Ilya Sandler (isandler) | Date: 2005-07-31 00:59 | |
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? |
|||
msg60790 - (view) | Author: Ilya Sandler (isandler) | Date: 2005-07-31 03:20 | |
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"... |
|||
msg60791 - (view) | Author: Joseph Heled (pepster) | Date: 2005-07-31 06:02 | |
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 |
|||
msg60792 - (view) | Author: Ilya Sandler (isandler) | Date: 2005-07-31 20:48 | |
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? |
|||
msg60793 - (view) | Author: Joseph Heled (pepster) | Date: 2005-08-01 02:25 | |
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 |
|||
msg60794 - (view) | Author: Ilya Sandler (isandler) | Date: 2005-08-07 20:36 | |
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? |
|||
msg60795 - (view) | Author: Ilya Sandler (isandler) | Date: 2005-08-24 03:42 | |
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. |
|||
msg82194 - (view) | Author: Daniel Diniz (ajaksu2) * | Date: 2009-02-16 00:27 | |
Will close this one as fixed by issue 1267629, unless someone voices disagreement. |
|||
msg82293 - (view) | Author: Benjamin Peterson (benjamin.peterson) * | Date: 2009-02-17 02:00 | |
Let's do it. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:12 | admin | set | github: 42230 |
2009-02-17 02:00:49 | benjamin.peterson | set | status: open -> closed nosy: + benjamin.peterson resolution: fixed messages: + msg82293 |
2009-02-16 00:27:19 | ajaksu2 | set | nosy:
+ ajaksu2 superseder: pdb: implement "until",fix for 1248119 messages: + msg82194 |
2005-07-30 21:12:46 | pepster | create |