Should pdb's next command accept an optional numeric argument? It would specify how many actual lines of code (not "line events") should be skipped in the current frame before stopping,
That would differ from gdb's "next <n>", which does "next" n times. It would be confusing if pdb accepted the same command, but it meant something different.
So, would implementing gdb's "until" command instead of "next N" be a better idea? In its simplest form (without arguments) "until" advances to the next (textually) source line... This would solve the original problem of getting over list comprehensions... There is a bit of a problem with abbreviation of "until": gdb abbreviates it as "u", while in pdb "u" means "up"...It might be a good idea to have the same abbreviations Ilya Problem: When the code contains list comprehensions (or for that matter any other looping construct), the only way to get quickly through this code in pdb is to set a temporary breakpoint on the line after the loop, which is inconvenient.. There is a SF bug report #1248119 about this behavior. On Sun, 7 Aug 2005, Ilya Sandler wrote:
On Sun, 7 Aug 2005, [ISO-8859-1] "Martin v. L?wis" wrote:
Ilya Sandler wrote:
Should pdb's next command accept an optional numeric argument? It would specify how many actual lines of code (not "line events") should be skipped in the current frame before stopping, [...] What do you think?
That would differ from gdb's "next <n>", which does "next" n times. It would be confusing if pdb accepted the same command, but it meant something different.
But as far as I can tell, pdb's next is already different from gdb's next! gdb's next seem to always go to the different source line, while pdb's next may stay on the current line.
The problem with "next <n>" meaning "repeat next n times" is that it seems to be less useful that the original suggestion.
Any alternative suggestions to allow to step over list comprehensions and such? (SF 1248119)
Plus, there is always a chance that <current line>+n is never reached, which would also be confusing.
That should not be a problem, returning from the current frame should be treated as a stopping condition (similarly to the current "next" behaviour)...
Ilya
So I'm -1 here.
Regards, Martin
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ilya%40bluefir.net