> > 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 > _______________________________________________ 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/archive%40mail-archive.com
