[Python-Dev] an alternative suggestion, Re: pdb: should next command be extended?

[Ilya Sandler]

> > 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ilya%40bluefir.net
>