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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 26 Jul 2008 10:41:38 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sourceware.org
> 
> On Sat, Jul 26, 2008 at 05:01:14PM +0300, Eli Zaretskii wrote:
> > > The bits added by
> > > this patch are similar to canned sequences of commands ("define"), but
> > > this is the first patch of hopefully many; you'll be able to use it
> > > for more than just macros.
> > 
> > Sorry, I don't understand this rationale (and what does it have to do
> > with macros? what macros?).  Please elaborate.
> 
> Sorry, I'm used to thinking of user-defined commands as macros.
> Sloppy choice of terminology.

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

> > My rationale is simple: we should have a single chapter for scripting,
> > because that's where a reader would look for information on how to
> > write GDB scripts.  If there's sense to distributing this information
> > between separate chapters, please explain what that is.
> 
> Ok, in that case I have an alternative suggestion: how about renaming
> the combined scripting chapter, and putting both Python scripting and
> the existing information in the new chapter?

I have no objections to renaming that chapter.

> I don't think Python makes sense as a section of "Canned Sequences of
> Commands", because Python scripts don't contain GDB commands.

The chapter name doesn't say "GDB Commands", it says just "Commands".
But let's not argue about that on which we agree ;-)

> 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.

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