pdb bug and questions

[R. Bernstein]

Stef Mientki <stef.mientki at gmail.com> writes:

> From: Stef Mientki <stef.mientki at gmail.com>
> Subject: Re: pdb bug and questions
> Newsgroups: comp.lang.python
> To: "python-list at python.org" <python-list at python.org>
> Date: Fri, 05 Sep 2008 22:06:19 +0200
>
> R. Bernstein wrote:
>> Stef Mientki <stef.mientki at gmail.com> writes:
>>
>>   
>>> hello,
>>>
>>> I'm trying to embed a debugger into an editor.
>>> I'm only interested in high level debugging.
>>> The first question is what debugger is the best for my purpose ?
>>> (pdb, pydb, rpdb2, smart debugger, extended debugger ?
>>>
>>> Second question, in none of the above debuggers (except rpdb2),
>>> I can find a  "break now",
>>> so it seems impossible to me to detect unlimited while loops ?
>>>     
>>
>> I am not sure what you mean by "break now". pdb and pydb allow direct
>> calls from a program to the debugger via set_trace (which in pydb is
>> deprecated in favor of I think the more descriptive name: debugger)
>>   But I suspect this is not what you mean to "detect unlimited while
>> loops"; pydb also has gdb-style signal handling that allows for entry
>> into the debugger when the debugged python process receives a
>> particular signal. "info handle" lists all of the interrupts and what
>> action is to be taken on each. See
>> http://bashdb.sourceforge.net/pydb/pydb/lib/node38.html
>>
>> However I believe that signals are only handled by the main thread; so
>> if that's blocked, the python process won't see the signal.
>>   
> Thanks,
> Yes, I think the trace option can do the job,
> certainly if I display every line.
> Didn't know pdb had something like settrace ( the information on pdb
> is very condensed ;-)

It sounds to me like there may be some confusion -- if at least on my
part. pdb's set_trace (with the underscore) is documented here:
http://docs.python.org/lib/module-pdb.html . Yes, perhaps it would be
nice if that document gave an example. But set_trace is a method call,
not an option.

There is a pydb debugger *command* called "set trace" as well as a
command-line option (-X --trace) which turns on line tracing and is
something totally different. It can be fun to use that with "set
linetrace delay" in an editor to allow one to watch the lines execute
as the program runs. I did this with emacs in this video:

http://showmedo.com/videos/video?name=pythonBernsteinPydbIntro&fromSeriesID=28

>>   
>>> For the moment I started with pdb, because most of the debuggers seems
>>> to be an extension on pdb.
>>> When I launch the debugger ( winXP, Python 2.5) from with my editor
>>>  python -u -m pdb  D:\\Data\\test_IDE.py
>>> I get this error
>>>  IOError: (2, 'No such file or directory', 'D:\\Data\test_IDE.py')
>>> NOTICE 1 backslash ----------------------------------^
>>>
>>> If I launch the debugger with
>>>  python -u -m pdb  D:/Data/test_IDE.py
>>> It runs fine.
>>>
>>> This looks like a bug to me.
>>> What's the best way to report these kind of bugs ?
>>>     
>>
>> winpdb, pydb and pdb (part of Python) all have Sourceforge projects
>> which have bug trackers. For pdb, in the past people includng myself,
>> have reported features, patches and bugs in the Python tracker;
>> eventually it gets handled. (Eventually in my case means a year or
>> so.) But if my information is incorrect or out of date, no doubt
>> someone will correct me.
>>   
> I'll take a look, for the sake of our children ;-)
>> As mentioned in the last paragraph, pydb also is a Sourceforge project
>> (part of bashdb) which has a tracker for bug reporting. Using the bug
>> tracker I think is better than discussing pydb bugs in c.l.p.
> c.l.p. ?

This newsgroup, comp.lang.python. 

>>  By
>> extension, I assume the same is also true for the other debuggers.
>>
>> Finally, I think rpdb2 is part of the winpdb project on Sourceforge
>> and again has a bug tracker. My sense is that Nir Aides is very good
>> about handling bugs reported in winpdb/rpdb.
>>   
> Yes I started with rpdb2,
> and indeed Nir Aides is very helpfull,
> but I think interfaceing rpdb2 is a little too difficult for me,
>
> For now I think pydb is the choice,
> better control and more functions than pdb,
> and almost just as easy.

If there are things that are unnecessarily awkward, and especially if
you can think of a way to make pydb better (that hasn't been suggested
before), please submit a feature request in the tracker for
pydb. Thanks.