Re: Python API - pretty printing complex types

[Andrew Oakley <andrew at ado dot is-a-geek dot net>]

n Wed, 09 Mar 2011 09:07:09 +0100
Joachim Protze <joachim.protze@wh2.tu-dresden.de> wrote:

> My first approach makes use of the undocumented (online-doc) 
> array-method of gdb.Type, that i put in a handy function -- the
> straight forward way.

OK, I was looking for that but couldn't find a way to do it.  I see
this is now documented which is nice.  It still doesn't handle more
complex cases though.

On Wed, 9 Mar 2011 09:54:49 +0100
André Pönitz <andre.poenitz@nokia.com> wrote:

> On Wednesday 09 March 2011 01:46:19 ext Andrew Oakley wrote:
> > [...] If API improvements are needed to do this I can have a go at 
> > writing the code (the current src/gdb/python code seems fairly 
> > easy to understand).
> 
> My 2 ct: The most dearly missing feature in the "official" pretty
> printer API is the possibility to create multi-level displays with
> "phony groups" and a flexible way to steer the "expansion state" of
> such groups.

I don't know about "expansion state" it feels like it is GDBs job to
manage that rather than the pretty printers themselves.  

I think it would be nice to be able to return pretty printers from the
children iterator of another pretty printer. This would allow "phony
groups" to be created - simply return another pretty printer for the
group and it will get printed in the usual fashion.  

I'm not sure what the best way to go about this is.  The problem is
finding out if the value returned should be handled as a pretty printer
or if it was something else.  I don't code much in python so I don't
really know what the usual API conventions are.  These are the options
I've thought of:

1. Use a different display_hint if pretty printers will be returned.
This is awkward if some of the children are simple types and some are
more complicated.  I'm not sure how it would interact with GDB/MI.

2. Create a new base class that pretty printers inherit from.  This
doesn't really feel like "the python way" - duck typing seems to be
common.  

3. Assume that objects that are not gdb.Value instances are pretty
printers.  This prevents any further extensions from working in the
same way.

4. Assume that objects with a to_string member are pretty printers.
This is the only required member of pretty printers and seems more in
line with other python libraries.  We probably want to check for this
after checking if the object was a gdb.Value, both for performance
reasons and to ensure no existing code has an nasty surprises.

I think option 4 is the best choice here and I'm happy to write a patch
to do this if there is some agreement that it is a reasonable decision
(and therefore might actually get committed).  

-- 
Andrew Oakley