Mike Meyer <[EMAIL PROTECTED]> writes: > 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.
Why would you have to choose? You've created a straw-man argument. No one has previously suggested *removing* tools or forcing one to use one and not the other! The thrust that started this thread and the intent was thoughts on *improving* debugging. You say you are happy with what you have. Great! But then out of the blue offer your non-help. And although that too wasn't the thrust of the thread either (soliciting volunteers), it's not like you apparently *had* been working on this either. Weird. > 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. Not if one uses *better* tools. :-) Again in this very thread another interpreter was mentioned which, alas, doesn't come with Python. But on many systems it is installed rather easily. It addresses some things that again in this thread have been noted as perhaps lacking in the stock Python-supplied interpreter. > I'm all to aware that not everyone writes code as easy to understand > as what I do. (And it just may be that not everyone finds reading your code as easy to understand as you think it is.) > 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. I heartily agree. (But I also can't help note that this may be a little bit of a self-serving statement.) > 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. Hmmm. If that's really your view of what makes a debugger, I can see why it's not all that important to you. But this could another one of your exaggerate-to-make-absurd arguments. Now that you mention it, stepping in pydb.py does have this little thing that seems just a little different from the norm. When one steps through a class or even a script with lots of methods/functions, the debugger seems to stop at every def, which isn't all that exciting. And say in contrast to gdb's step/next, you can't give a count. (Perl allows one to enter an arbitrary expression to step/next into). These do tend to make stepping less useful. But as with the "restart" command that was mentioned at the beginning of the thread, it wasn't all that hard to address in the current code base. > Pretty much > everything else that a debugger does can be done by other tools. So tell me what tools you have to set a breakpoint somewhere in a program possibly based on variable values, inspect arbitrary values as you see fit and perhaps change them, and then either continue or restart the program depending on how long it took to get to the point and how messed up things were when you got there? None of this involves stepping, so by your definition it's something that doesn't need a debugger. > As > those tools improve, the value of the debugger decreases. Python has > very good other tools. The argument also goes the other way. If one has a debugger that's lacking -- and it looks to me that pdb.py is a little bit neglected (in some cases I would even say not pythonic)-- then, sure, people are going to try to find ways to avoid using it. This too was mentioned on this thread. Without a doubt Python has good tools. And no doubt they will continue to improve as perhaps they should. But I don't see this as an argument for not to improving debugging in Python as well. -- http://mail.python.org/mailman/listinfo/python-list
