[EMAIL PROTECTED] (R. Bernstein) writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> I don't use pdb a lot either - and I write a *lot* of Python. > Some of us may have to *read* a lot of python. (For example I know > many people including myself who have had to deal with code written by > consultants who wrote a *lot* of code but are no longer *maintaining* > the code for various reasons). And one place debuggers tend to come in > handy is in focused or problem-solving of others' code.
I also read a lot of Python. Cleaning up that which was created by others is a common role for consultants. >> If not, rather than load the application into a debugger >> and futz with that, it's simpler to fire up the interpreter, import >> the module that is misbehaving, instantiate and experiment on the >> classes with bogus behavior. > If you have a good understanding of the code that may be a good thing. > If you don't and debugging is easy (and I think someone else had > suggested python may be in some circumstances lacking here), then > debugging is desireable. I've noticed that different people pefer > different things. And that's why there's race-track betting. In my experience, a good way to gain an understanding of the code is to play with it in the interpreter. Being able to feed arbitrary things to methods and observe the results is invaluable. Being able to step through the code line at a time also helps, and it's a good thing that Python lets you do both. But if I had to choose between being able to play with objects interactively or being able to step through code, I'll take the interactive interpreter every time. >> If you write code that consists of >> reasonably small methods/functions, these tools work *very* well for >> chasing down bugs. > It would be simple-minded to assert that everyone who writes python > code works uses your tools or writes code as easy to understand as you > imply your code is. Well, the tools I'm talking about here are ones that Python comes with. It may be simple-minded to assert that everyone who writes Python code uses the tools that come with Python, but it's not very bright to not use the tools that come with the language. I'm all to aware that not everyone writes code as easy to understand as what I do. The correct solution for bad code was elucidated by Kernighan and Plauger nearly 30 years ago: "Don't fix bad code. Rewrite it." I don't do that nearly often enough. >> Given those two tools, I find I use pdb maybe once a year. I probably >> wouldn't miss it if it vanished. > I guess you are in agreement with many POSIX shell (e.g bash, Bourne > and Korn) developers. You see, before I wrote a debugger for bash > (http://bashdb.sourceforge.net) there just weren't any such > things. :-) And those languages are very very old maybe 20 years or > so. A good debugger is a valuable thing, and I've used some incredible debuggers, including one that actually implemented DWIM. Stepping through the code is one of the least valuable thing a debugger does, but it's also the thing that makes it a debugger. Pretty much everything else that a debugger does can be done by other tools. As those tools improve, the value of the debugger decreases. Python has very good other tools. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
