Winpdb - A Platform Independent Python Debugger Who Needs Debuggers?
Judging by download numbers Winpdb is used by approximately 1 in every 500 Python programmers. Given that Python is easy to learn and use, I am still puzzled by this number.
This is what Wikpedia has to say about debuggers: “The importance of a good debugger cannot be overstated. Indeed, the existence and quality of such a tool for a given language and platform can often be the deciding factor in its use, even if another language/platform is better-suited to the task.”
Is Winpdb useful enough to expect wider use? or do you feel it is not ready yet?
Winpdb is one of the hidden gems of the python world, not nearly enough people know about it. I’m happy to see that Winpdb is packaged in the upcoming version of Ubuntu. Perhaps a screencast demoing how to use Winpdb would be useful?
But contrast with:
http://gilesbowkett.blogspot.com/2007/10/debugger-support-considered-harmful.html
Are you sure those are the numbers? Everybody I know uses winpdb and it I wouldn’t survive without it.
Maybe people just grab it with SVN and it goes uncounted?
Anyway, you are doing an avodak kodesh. Please don’t stop
What about the denominator? Not everyone who downloads Python is a programmer, and summing programming tools will multiply count a lot of people. How did you calculate?
What are the download numbers? And how many Python programmers are there out there?
Winpdb is downloaded (Including SVN reads) 1000 times per month, out of which roughly 650 are for Windows OS.
The Python Windows installer is downloaded about 300,000 times per month:
http://mail.python.org/pipermail/python-dev/2006-December/070291.html
I assume most downloads on Windows are by potential programmers and that this ratio applies to Linux as well.
This number does not include use of Winpdb as plugin in editors such as SPE or Ulipad since I have no idea how many people actually use the Winpdb plugin in these editors.
Winpdb is a fabulous tool, especially for debugging embedded python. It is true I don’t need a debugger much in python for my own code. But when familiarizing myself with code written by someone else, or having my embedded python code being called by others with unexpected arguments, winpdb can save the day.
As to stats - I got it now. Because of linux distributions, the numbers for linux are difficult to get, but you are using the numbers for windows and extrapolating to linux, which is probably more accurate. Ok.
Hmmm… tools like Stani’s Python Editor (SPE) include winpdb and are likely difficult to count. That is where I get it.
I’d imagine that the majority of python programmers might not even know what a debugger is. Python has quite a low barrier to entry so many python programmers are learning to program for the first time and so they don’t know what they are missing.
Also I’d guess that most python programmers write fairly simple scripts where print statements are sufficient for debugging.
I. just. didnt. know. about. it. Amazing tool.
Add me to the “me, too” list. Ever since starting to python (is this a verb yet?) I was *hoping* something like this would exist. Everybody is saying Python is so easy but I find it not so. I am an experienced embedded C programmer and am used to have a complete command and understanding of ‘my’ language. In Python every time I touch it I learn some new, amazing feature/function that I didn’t know about before and I feel I will never truly, completely understand it. Some of the concepts just require a complete “starting over” mindset if you come from C. Difficult to attain IMO.
Anyway, this will help me a lot speeding up my learning curve since many (most) significantly sophisticated Python programs out there are very poorly documented. In order to understand them you need a good debugger and step through.
love winpdb and it is essential to tearing into “it’s not supposed to do that” code. would be wonderful ot you could make 3 things real.
1: breakpoint on predicate. think of this as an assertion that invokes winpdb instead of an stack trace.
2: run full speed until breakpoint or assertion. I’ve had code run for 2-4 hours (full tilt) before failing and needing a debugger. running with winpdb is, er, painful.
3: grabbing a running program. yea, a holy grail.
Hi piedoggie,
1. You can have conditional breakpoints with Winpdb but you need to define them from the Winpdb console. For example to set a breakpoint on line 100 that breaks if variable i == 5 type the following in the Winpdb console:
bp 100, i == 5
type ‘help bp’ at the console for more information.
Another way to cause a breakpoint is from the code with rpdb2.setbreak(). For example:
if i == 5: rpdb2.setbreak()
2. You can run at near-full-speed if you disable all breakpoints and let the debugger run. Make it break from the code with rpdb2.setbreak() where needed.
3. You can grab a running program but only if it has the rpdb2 server running with rpdb2.start_embedded_debugger(some-password). If no breakpoints are set it will run at near-full-speed. It is recommended to start the debugger server when the program starts but if your program does not use threads you can also start the debugger at the last minute (This way it will run at full speed). For example in an assertion:
if i == 5:
print “Hey, its time to attach with a debugger!â€
rpdb2.start_embedded_debugger(some-password)
You can read more about this in:
http://winpdb.org/?page_id=9
Nir
pdb has been very useful for me although my system setup has weird issues (not winpdb’s fault) that make winpdb hard for me to use. I think python culture is not acclimated enough to using debuggers and not enough people know about winpdb yet. This is a shame.
By the way Giles Bowkett closed off comments on his post I guess because of too many people pointing out how wrong it was. He says debuggers are an artifact of fixing C pointer errors, but that’s wrong, C debuggers (even gdb) generally aren’t that great, and the best debuggers have been for languages like smalltalk and lisp. Even Haskell has a debugger now, and its users welcome it even though the language no pointers, very little use of data mutation, and a very powerful static type system that stops a heck of a lot of errors from ever happening.
I’m on a Mac and just starting out, does it run on a Mac?
I use a debugger, but I use the commercial WingIDE, and their debugger is fantastic. I’ve not used Winpdb, so I can’t compare, but I certainly use a debugger, just not this one.
Paul,
Giles Bowkett is not alone. It seems many people do not consider debuggers useful or needed, even in C. In fact, Linus Torvalds has an interesting opinion against the inclusion of a kernel debugger in the Linux development environment:
http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.html
As for Python and Ruby, it is possible that the culture of discouraging the use of debuggers was driven by lack of a good debugger in the first place, just as I neglect writing unit tests because I have a useful debugger at hand.
Without diving into anecdotal examples, I frequently run into complex problems where a debugger proves indispensable, either when debugging Winpdb itself or other people’s code.
Beginner,
Winpdb used to work on Mac and possibly still does, but I have not tested it for a while on that system.
Joshua,
The WingIDE debugger is excellent. Second best only to Winpdb
Hi,
I’ve been developing professionally for 22 years and though I’m still learning new stuff all the time, in my opinion a good debugger is invaluable. Ever since I first started debugging C code on Vax/VMS systems, and then onto TurboC, Visual Studio and now Python WingIDE / WinPDB I never understood my fellow developers who didn’t take the time to learn how to make good use of a debugger IDE. Right now the guys I work with seem to prefer putting print statements in their code and looking at tracebacks rather than use WingIDE or WinPDB. WinPDB is ENORMOUSLY useful for debugging remote projects, and far easier to set up than doing remote debugging with WingIDE. Just the concepts of being able to single step through your code, and set breakpoints is INCREDIBLY powerful. If you’re doing anything complex at all, I personally can’t understand NOT using a debugger, and WinPDB is a great one.
Doug
Nir,
you write:
….just as I neglect writing unit tests because I have a useful debugger at hand.
Unit tests serve another purpose: With Unit tests you define and document the interface of your functions/modules/classes with the utmost rigor.
This allows you to do refactoring with the proof that your interface is not broken afterwards. So they help you to keep your builds clean.
You certainly don’t want to do that interactively in a debugger.
Debuggers and Unit Tests are completely separate tools with different uses.
Norbert
Nir,
I’ve always thought a good debugger can be useful and sometimes invaluable. I spent a couple of hours today looking for a way to debug vim scripts and Winpdb is exactly what I wanted.
It became clear on my travels through the web lots of people need a debugger for vim/python too. I added a little summary to the embedded documentation page. Hope you think its a useful inclusion but cast you eye over it if you get a chance to make sure it all seems sensible to use.
Thanks for Winpdb!
Peter.