[Python-3000] Debuggers was Re: What do do about IDLE?

Guido van Rossum guido at python.org
Thu May 11 08:01:09 CEST 2006


On 5/10/06, Edward C. Jones <edcjones at comcast.net> wrote:
> Talin <talin at acm.org> wrote:
>  > I don't think we really need an IDE, but a debugger that is
>  > at least able to show source code, call stack, and local
>  > variables in a window would be extremely useful.
>  >
>  > So my thought is this: How hard would it be to make
>  > a curses-based debugger?
>
> For a good terminal oriented debugger, see the old Borland Debugger.
>
> I would like to see a debugger that sees the C or C++ code in my buggy
> extension modules but does not see the internals of the Python interpreter.

I don't know the Borland debugger, and I consider a cross-language
debugger (while useful) rather out of scope and also rather unlikely
to happen.

But I think there's something very useful in this area that we ought
to implement. It's not strictly a py3k thing, but probably requires
sufficient forethought that we might as well build it for py3k first.
This is a standard remote debugging API. I think that one of the
challenges here is to factor it so that the actual RPC mechanism used
is independent from the rest of the API; that seems necessary because,
if successful, the mechanism must be usable by every Python-capable
IDE, and they all have their own RPC already. It *must* be capable to
be run over a unix-domain socket or a localhost TCP connection. But
the same API should also be usable (and be implementable efficiently,
preferably without serializing+deserializing) for use by a traditional
in-process local debugger.

Every IDE developer realizes this is needed, realizes that it doesn't
exist, realizes that there's no time to sit down and do it right,
sighs, and hacks something together that is uniqe and exclusive to the
requirements of that IDE's debugger. This is wasted time and we should
be able to do better if we plan it right.

Anybody?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list