Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support

[Tom Tromey <tromey@redhat.com>]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> So are you saying that adding Python will enable features that are
Eli> beyond user-defined commands (a.k.a. scripting)?  If so, what are
Eli> those features?

The python programmer will be able to access nearly everything.  We
already have (on the branch) representations for threads, breakpoints,
commands, internal functions (a new feature), blocks, frames, symbols,
symbol tables, and values.  We'll add more, too (at least types) --
but we're going through a round of cleanup-and-submit first.

>> For example, we can pass a value or type and get back a friendlier
>> display value or type; the long-requested C++/STL pretty-printing
>> support.

Eli> Maybe I'm missing something, because I don't see how this is different
Eli> from what we have now.  For example, the .gdbinit file distributed
Eli> with Emacs already pretty-prints Emacs Lisp data types, as do the
Eli> various GDB extensions for printing Qt data types that float around.
Eli> They are all written in the current scripting CLI language.  How will
Eli> Python be different in this department?

It will be integrated into "print" and will work with MI as well.

Lots of projects distribute .gdbinit-style files like this.  They all
are lacking in various ways, due to shortcomings of gdb's command
language.  The Python approach will fix all of this.

Pretty-printing is just one feature though.  I want to push things
much farther.

Tom