your favorite debugging tool?
Esmail
What is your favorite tool to help you debug your
code? I've been getting along with 'print' statements
but that is getting old and somewhat cumbersome.
I'm primarily interested in utilities for Linux (but
if you have recommendations for Windows, I'll take
them too :)
I use emacs as my primary development environment, FWIW.
Someone mentioned winpdb .. anyone have experience/comments
on this? Others?
Thanks,
Esmail
Aahz
Esmail <ebo...@hotmail.com> wrote:
>
>What is your favorite tool to help you debug your code? I've been
>getting along with 'print' statements but that is getting old and
>somewhat cumbersome.
Despite the fact that I've been using Python for more than a decade,
print is still my mainstay (or possibly logging to a file).
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"I support family values -- Addams family values" --www.nancybuttons.com
Ben Finney
> What is your favorite tool to help you debug your code?
A “print” statement (or equivalent, like logging output).
> I've been getting along with 'print' statements but that is getting
> old and somewhat cumbersome.
Whenever a simple output statement is too cumbersome for debugging, I
take it as a sign that the program is too cumbersome to follow.
My debugging questions at that point are best taken to the unit test
suite: record the questions and the expected answers, so that in the
future anyone can get the benefit of them in a repeatable and automated
fashion.
--
\ “The power of accurate observation is frequently called |
`\ cynicism by those who don't have it.” —George Bernard Shaw |
_o__) |
Ben Finney
Hendrik van Rooyen
> In article <mailman.227.1250951...@python.org>,
>
> Esmail <ebo...@hotmail.com> wrote:
> >What is your favorite tool to help you debug your code? I've been
> >getting along with 'print' statements but that is getting old and
> >somewhat cumbersome.
>
> Despite the fact that I've been using Python for more than a decade,
> print is still my mainstay (or possibly logging to a file).
Same here, although I have not been abusing python for as long as Aahz has
been using it.
I find that python pretty much does more or less what I expect it to, and
where it does not, a print quickly gets me to RTFM when I have been rolling
along under intuition.
And the final arbiter is of course the interactive prompt.
- Hendrik
Ben Finney
> And the final arbiter is of course the interactive prompt.
Oh yes, of course I forget to mention that!
Write your code so it can be imported, and write your functionality so
it has narrow interfaces, and you can do whatever inspection is needed
from the interactive prompt.
--
\ “We have to go forth and crush every world view that doesn't |
`\ believe in tolerance and free speech.” —David Brin |
_o__) |
Ben Finney
Robert Kern
> Hi all,
>
> What is your favorite tool to help you debug your
> code? I've been getting along with 'print' statements
> but that is getting old and somewhat cumbersome.
>
> if you have recommendations for Windows, I'll take
> them too :)
>
> I use emacs as my primary development environment, FWIW.
> Someone mentioned winpdb .. anyone have experience/comments
> on this? Others?
I am frequently in the IPython interactive prompt for testing out stuff and even
as the main way of running my code. It has a nice feature that when you get a
traceback, you can open up pdb post-mortem.
In [8]: def f(x):
...: y = 1 / x
...: return y
...:
In [9]: f(1)
Out[9]: 1
In [10]: f(0)
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
/Users/rkern/<ipython console> in <module>()
/Users/rkern/<ipython console> in f(x)
ZeroDivisionError: integer division or modulo by zero
In [11]: %debug
> <ipython console>(2)f()
ipdb> print x
0
I have a little function that I've been using recently to print out the function
I am currently in along with the arguments:
def whereami():
""" Print the current function call.
import kerntrace;kerntrace.whereami()
"""
import inspect
frame = inspect.currentframe(1)
args, varargs, varkw, f_locals = inspect.getargvalues(frame)
if args[:1] == ['self']:
del args[0]
print '%s%s' % (frame.f_code.co_name, inspect.formatargvalues(args, varargs,
varkw, f_locals))
I think pdb is okay, but I am looking forward to pydbgr's completion.
http://code.google.com/p/pydbgr/
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
Francesco Bochicchio
Although like the others I mostly use print statements, in a few
occasions I have found useful to resort to a full-blown debugger. Of
the ones I have used, the one provided by eclipse+pydev is the one I
liked most. The one in pywin32 IDE is basic but can be useful.
With emacs, one should be able to use pydb, but I never used that,
although emacs is my most used programming environment on most
platforms.
About print cumbersomeness, I agree. As I posted elsewhere, I'd like a
'trace mechanism' with the
following characteristics:
1. Can be enabled/disabled easily, and when it is dsabled it has no
runtime costs ( i.e. disabled 'trace' statements do not generate any
code)
2. Can be enabled/disabled on a class/function/method base (e.g.
enable only the trace in a method ), to only get the trace output from
the code you are debugging
3. Make it easy to report the context (i.e. generate messages which
starts with 'class.method:', without
hanving to hardcode class name and method name).
I know about the 'trace' and 'logging' modules, but neither seem to
satisfy the above requirements. Probably using python introspection
and metaprogramming features it is possible to do somethinmg that
covers at least 2 and 3. Not sure about one (using if __debug__ you
can reduce the runtime cost when
compiling in optimized mode, but probably not nullify it).
Ciao
-----
FB
David
>
> I use emacs as my primary development environment, FWIW.
> Someone mentioned winpdb .. anyone have experience/comments
> on this? Others?
I use Winpdb on Windows and I feel quite comfortable. The interface is not
so clever as more advanced (and expensive, winpdb is free) debuggers but
there is all yuo need for deep-source debugging.
It is especially suited for multi threaded programs and GUI debugging, where
command line debugging is a pain.
It supports remote debugging over encrypted connection also.
regards
David
Jean-Michel Pichavant
> Hi all,
>
> What is your favorite tool to help you debug your
> code? I've been getting along with 'print' statements
> but that is getting old and somewhat cumbersome.
>
> I'm primarily interested in utilities for Linux (but
> if you have recommendations for Windows, I'll take
> them too :)
>
> Someone mentioned winpdb .. anyone have experience/comments
> on this? Others?
>
> Esmail
>
I execute the program within IPython.
>>> run test.py
I usually write a CTRL+C except clause that will spawn an Ipython shell
so I can inspect the namespace at that time.
I'm also using the ipdb to spawn the debugger.
import IPython
ipdb = IPython.Debugger.Pdb(color_scheme='Linux')
ipdb.set_trace()
it spawns the IPython debugger, allowing step by step execution, code
inspection, changing the namespace. You get all the IPython benefits
(espacially the TAB completion, history ...)
I used to proceed with print statements, but they are some situations
where it won't just make it. Sometimes the code is so complex you can't
anticipate all the required prints to catch a bug.
JM
Esmail
thank you all for your suggestions/comments.
While I do believe in a minimalist approach (part of the reason
I find Python so appealing), using print statements sometimes
only goes so far (for me).
I probably should look into using iPython in the context of
debugging (I already use this shell).
For now I ended up giving winpdb a whirl and it did help me find
the bug that had been elusive to my print statement approach :-)
Thanks again .. and if there are additional postings, I'll be
reading them too with great interest.
Esmail
Paul Rubin
> What is your favorite tool to help you debug your
> code? I've been getting along with 'print' statements
> but that is getting old and somewhat cumbersome.
Beyond print statements, I use pdb a lot. Winpdb (www.winpdb.org) is
even better, but is kind of cumbersome to get working.
Robert Marshall
And you can run it (pdb) within emacs - though I find a little roughness
in working out the exact interactions keeps ending up (ie the source
buffer displayed) in the wrong stack frame - afaict
Robert
--
La grenouille songe..dans son château d'eau
Links and things http://rmstar.blogspot.com/
Michele Simionato
>
> What is your favorite tool to help you debug your
> code?
The times when I would just use 'print' are long past. Nowadays I
spend lots of my time
with code written by others than myself. I use pdb all the time, and
now also ipdb
(ipdb is very cool if you are used to ipython).
M.S.
Esmail
Hi,
2 quick questions.
Re pdb, if you have a 'pointer' (ie reference) to an object, is there
an easy way to dump out its contents, ie all of its members short of
writing a method that does that and then calling it?
Anyone know what is going on with the winpdb site? I haven't been able to
get to it in the last few days.
Thanks,
Esmail
Esmail
Never heard of ipdb, I'll have to check it out.
Thanks,
Esmail
Esmail
> On 24 Aug 2009, Paul Rubin wrote:
>
>> Esmail <ebo...@hotmail.com> writes:
>>> What is your favorite tool to help you debug your
>>> code? I've been getting along with 'print' statements
>>> but that is getting old and somewhat cumbersome.
>> Beyond print statements, I use pdb a lot. Winpdb (www.winpdb.org) is
>> even better, but is kind of cumbersome to get working.
>
> And you can run it (pdb) within emacs - though I find a little roughness
> in working out the exact interactions keeps ending up (ie the source
> buffer displayed) in the wrong stack frame - afaict
Thanks Robert, I'll have to give that a try.
Esmail
Ben Finney
> While I do believe in a minimalist approach (part of the reason I find
> Python so appealing), using print statements sometimes only goes so
> far (for me).
Right, which is where the Python interactive interpreter (which I failed
to mention in my initial response) comes in as my favourite debugging
tool.
--
\ “When I was a kid I used to pray every night for a new bicycle. |
`\ Then I realised that the Lord doesn't work that way so I stole |
_o__) one and asked Him to forgive me.” —Emo Philips |
Ben Finney
Esmail
Ben Finney wrote:
>
> Whenever a simple output statement is too cumbersome for debugging, I
> take it as a sign that the program is too cumbersome to follow.
I'll have to think about this .. though my gut says this is true :-)
re your other point about the interactive shell, I agree it's useful, but
to me still doesn't quite do what a full-fledged debugger can - but perhaps
that is a reflection of my skill with the shell at this point.
Always more to learn.
Esmail
Jean-Michel Pichavant
> Hi Ben,
>
> Ben Finney wrote:
>>
>> take it as a sign that the program is too cumbersome to follow.
>
>
can't always avoid writing complex code. Python does not get your code
more complex than your algorithm, but it cannot always simplify it.
Ben is right when he says that code can often be written in a more
simpler manner, but they are some occasions when you have to write
complex code, that the print debug statement won't be efficient enough
to sort things out. I personally develop/maintain a full application
written in python (and quite complex for some parts), using the ipdb
debugger just saved my hours (days) of headache about some very
difficult bug to spot
> re your other point about the interactive shell, I agree it's useful, but
> to me still doesn't quite do what a full-fledged debugger can - but
> perhaps
> that is a reflection of my skill with the shell at this point.
>
> Always more to learn.
>
> Esmail
>
90% of the time, print statements + ipython shell will do the trick. The
post mortem debugging is also very useful. Execute your python file in
ipython, then when it exits upon exception, execute
>>> import pdb ; pdb.pm()
You can then inspect the symbols easily.
JM
Ben Finney
> Hi Ben,
>
> Ben Finney wrote:
> >
> > Whenever a simple output statement is too cumbersome for debugging, I
> > take it as a sign that the program is too cumbersome to follow.
>
> I'll have to think about this .. though my gut says this is true :-)
Note that it's only a sign, *not* an ironclad guarantee. But it's the
right way to bet, IME.
> re your other point about the interactive shell, I agree it's useful,
> but to me still doesn't quite do what a full-fledged debugger can -
> but perhaps that is a reflection of my skill with the shell at this
> point.
This, on the other hand, I find even more consistent: if the code can't
be effectively inspected from the interactive interpreter, that's a sure
sign that its external interfaces are poor or its internal dependencies
too tightly coupled; or more likely both.
Fixing that set of problems is both useful for debugging *and* good
design.
--
\ “Alternative explanations are always welcome in science, if |
`\ they are better and explain more. Alternative explanations that |
_o__) explain nothing are not welcome.” —Victor J. Stenger, 2001-11-05 |
Ben Finney
Falcolas
wrote:
> On Saturday 22 August 2009 16:49:22 Aahz wrote:
>
>
> > Esmail <ebo...@hotmail.com> wrote:
> > >What is your favorite tool to help you debug your code? I've been
> > >getting along with 'print' statements but that is getting old and
> > >somewhat cumbersome.
>
> > Despite the fact that I've been using Python for more than a decade,
> > print is still my mainstay (or possibly logging to a file).
>
> Same here, although I have not been abusing python for as long as Aahz has
> been using it.
>
>
> And the final arbiter is of course the interactive prompt.
>
> - Hendrik
The only thing I would add to these comments is the fact that writing
helper functions for using print with complicated routines is very
simple, though perhaps not obvious. For example, consider the
following for unrolling list comprehensions or generators without
having to re-write them:
def trace(iterable):
for x in iterable:
print x
yield x
~G
Robert Kern
> Esmail<ebo...@hotmail.com> writes:
>
>> Hi Ben,
>>
>> Ben Finney wrote:
>>>
>>> Whenever a simple output statement is too cumbersome for debugging, I
>>> take it as a sign that the program is too cumbersome to follow.
>>
>> I'll have to think about this .. though my gut says this is true :-)
>
> Note that it's only a sign, *not* an ironclad guarantee. But it's the
> right way to bet, IME.
>
>> re your other point about the interactive shell, I agree it's useful,
>> but to me still doesn't quite do what a full-fledged debugger can -
>> but perhaps that is a reflection of my skill with the shell at this
>> point.
>
> This, on the other hand, I find even more consistent: if the code can't
> be effectively inspected from the interactive interpreter, that's a sure
> sign that its external interfaces are poor or its internal dependencies
> too tightly coupled; or more likely both.
And a debugger is a great tool to help you figure out exactly why your code
doesn't actually have the wonderful decoupling that you thought you designed
into it so you can fix it. :-)
Robert Kern
It's not really a separate thing, just the pdb integration into the IPython
interactive shell (which I highly recommend that you check out).
Esmail
> Esmail <ebo...@hotmail.com> writes:
>
>> Hi Ben,
>>
>> Ben Finney wrote:
>>> Whenever a simple output statement is too cumbersome for debugging, I
>>> take it as a sign that the program is too cumbersome to follow.
>> I'll have to think about this .. though my gut says this is true :-)
>
> Note that it's only a sign, *not* an ironclad guarantee. But it's the
> right way to bet, IME.
:-) .. I took it as a rule of thumb too .. I didn't meant to imply
anything more serious. These design guidelines help though.
Thanks,
Esmail
Paul Rubin
> My normal debug technique is wolf fencing* (eg; print statements)
That method was formerly completely automated on the web:
http://www.st.cs.uni-saarland.de/askigor/faq.php
It was amazing. Further info is here:
Marius Gedminas
> Re pdb, if you have a 'pointer' (ie reference) to an object, is there
> an easy way to dump out its contents, ie all of its members short of
> writing a method that does that and then calling it?
Usually
pp vars(your_object)
does what you want