[Python-Dev] an alternative suggestion, Re: pdb: should next command be extended?
ilya at bluefir.net
Tue Aug 9 03:15:26 CEST 2005
> > 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
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
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"
> > So I'm -1 here.
> > Regards,
> > Martin
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ilya%40bluefir.net
More information about the Python-Dev