pdb: should next command be extended?
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. Solution: 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, i.e "next 5" would mean stop when line>=line_where_next_N_happened+5 is reached. This would allow to easily get over/out of loops in the debugger What do you think? Ilya
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. Plus, there is always a chance that <current line>+n is never reached, which would also be confusing. So I'm -1 here. Regards, Martin
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
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
Ilya Sandler wrote:
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...
I like that idea.
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
Indeed. I don't know much about pdb internals, but I think "u" should become unbound, and "up" and "unt" should become the shortest abbreviations. Regards, Martin
On Sun, Aug 07, 2005, Ilya Sandler wrote:
Solution:
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,
At OSCON, Anthony Baxter made the point that pdb is currently one of the more unPythonic modules. If you're feeling a lot of energy about this, rewriting pdb might be more productive. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything.
At OSCON, Anthony Baxter made the point that pdb is currently one of the more unPythonic modules.
What is unpythonic about pdb? Is this part of Anthony's presentation online? (Google found a summary and slides from presentation but they don't say anything about pdb's deficiencies) Ilya On Mon, 8 Aug 2005, Aahz wrote:
On Sun, Aug 07, 2005, Ilya Sandler wrote:
Solution:
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,
At OSCON, Anthony Baxter made the point that pdb is currently one of the more unPythonic modules. If you're feeling a lot of energy about this, rewriting pdb might be more productive. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/
The way to build large Python applications is to componentize and loosely-couple the hell out of everything.
[Ilya Sandler wrote]
At OSCON, Anthony Baxter made the point that pdb is currently one of the more unPythonic modules.
What is unpythonic about pdb? Is this part of Anthony's presentation online? (Google found a summary and slides from presentation but they don't say anything about pdb's deficiencies)
Kevin Altis was policing him to 5 minutes for his lightning talk so he didn't have a lot of time to elaborate. :) His slides were more of the Lawrence Lessig, quick and pithy style rather than lots of explanatory text. I think overridability, i.e. being about to subclass the Pdb stuff to do useful things, or lack of it was the main beef. Mostly Anthony was echoing comments from others' experiences with trying to work with the Pdb code. Trent -- Trent Mick TrentM@ActiveState.com
On Monday 08 August 2005 20:13, Ilya Sandler wrote:
At OSCON, Anthony Baxter made the point that pdb is currently one of the more unPythonic modules.
What is unpythonic about pdb? Is this part of Anthony's presentation online? (Google found a summary and slides from presentation but they don't say anything about pdb's deficiencies)
It was a lightning talk, I'll put the slides up somewhere at some point. My experience with pdb is that it's more or less impossible to extend or subclass it in any way, and the code is pretty nasty. In addition, pretty much everyone I asked "which modules in the std lib need to be seriously fixed" listed pdb first (and sometimes first, second and third). Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On Aug 11, 2005, at 3:02 PM, Anthony Baxter wrote:
On Monday 08 August 2005 20:13, Ilya Sandler wrote:
At OSCON, Anthony Baxter made the point that pdb is currently one of the more unPythonic modules.
What is unpythonic about pdb? Is this part of Anthony's presentation online? (Google found a summary and slides from presentation but they don't say anything about pdb's deficiencies)
It was a lightning talk, I'll put the slides up somewhere at some point. My experience with pdb is that it's more or less impossible to extend or subclass it in any way, and the code is pretty nasty. In addition, pretty much everyone I asked "which modules in the std lib need to be seriously fixed" listed pdb first (and sometimes first, second and third).
One thing PDB needs is a mode that runs as a background thread and opens up a socket so that another Python process can talk to it, for embedded/remote/GUI debugging. This is what IDLE, Wing, and WinPDB (haven't tried it yet <http://www.digitalpeers.com/pythondebugger/ index.html>) do. Unfortunately, most of the other Python IDE's run interpreters and debuggers in-process, so it makes them unsuitable for developing GUI and embedded apps and opens you up for crashing the IDE as well as whatever code you're trying to fix. -bob
One thing PDB needs is a mode that runs as a background thread and opens up a socket so that another Python process can talk to it, for embedded/remote/GUI debugging.
There is a patch on SourceForge python.org/sf/721464 which allows pdb to read/write from/to arbitrary file objects. Would it answer some of your concerns (eg remote debugging)? The patch probably will not apply to the current code, but I guess, I could revive it if anyone thinks that it's worthwhile... What do you think? Ilya
Ilya Sandler wrote:
There is a patch on SourceForge python.org/sf/721464 which allows pdb to read/write from/to arbitrary file objects. Would it answer some of your concerns (eg remote debugging)?
The patch probably will not apply to the current code, but I guess, I could revive it if anyone thinks that it's worthwhile...
What do you think?
I just looked at it, and yes, it's a good idea. As you say, the patch is currently out of date. It is probably easiest to redo it from scratch; if you do, please use print redirections instead of self.file.write. Regards, Martin
On Mon, 17 Apr 2006, [ISO-8859-1] "Martin v. L?wis" wrote:
There is a patch on SourceForge python.org/sf/721464 which allows pdb to read/write from/to arbitrary file objects. Would it answer some of your concerns (eg remote debugging)?
I guess, I could revive it if anyone thinks that it's worthwhile...
I just looked at it, and yes, it's a good idea.
Ok, I'll look into it and submit as a new SF item (probably within 2-3 weeks)... A question though: the patch will touch the code in many places and so is likely to break other pdb patches which are in SF (e.g 1393667( restart patch by rockyb) and 1267629('until' patch by me)). Any chance of getting those accepted/rejected before remote debugging patch? Thanks Ilya
participants (6)
-
"Martin v. Löwis" -
Aahz -
Anthony Baxter -
Bob Ippolito -
Ilya Sandler -
Trent Mick