Re: Python: add field access by name and standard python mapping methods to gdb.Type

[Doug Evans <dje@google.com>]

On Fri, Sep 16, 2011 at 8:27 AM, Paul Koning <paulkoning@comcast.net> wrote:
>
> Below is an update with the various comments addressed.

Hi.  This email is for just a couple of formatting nits.

> 2011-09-15  Paul Koning  <paul_koning@dell.com>
>
>        * python/py-type.c (make_fielditem, typy_field_names, typy_items,
>        typy_length, typy_get, typy_has_key, typy_make_iter,
>        typy_iterkeys, typy_iteritems, typy_itervalues, typy_iter,
>        typy_iterator_iter, typy_iterator_iternext,
>        typy_iterator_dealloc): : New functions to implement standard
>        Python mapping methods on gdb.Type object.
>        (gdb.TypeIterator): New Python type.
>        * python/python-internal.h (gdbpy_iter_kind): New enum.
>        * doc/gdb.texinfo (gdb.Type): Document field access by dictionary
>        key syntax.

Technically speaking, the rule is you can't extend a parenthesized name list
over multiple lines.  At least that's the rule I've been asked to follow.
I'd like to see some flexibility here, and I'm not asking you change this here.
Just pointing it out.

> +/* Helper function for Type standard mapping methods.  Returns a
> +   Python object for field i of the type.  "kind" specifies what to
> +   return: the name of the field, a gdb.Field object corresponding to
> +   the field, or a tuple consisting of field name and gdb.Field
> +   object.  */
> +static PyObject *
> +make_fielditem (struct type *type, int i, enum gdbpy_iter_kind kind)

For functions the coding standards say to have a blank line between
its comment and definition.
I realize parts of gdb don't follow this rule, but this rule I like :-),
it is documented, and I'd like to not make things worse.

This needs to be fixed in several places.