[Python] Allow attribute references to gdb.Value objects

[Python] Allow attribute references to gdb.Value objects

[Paul Koning]

It would be more natural to be able to reference fields of a gdb.Value by the standard field (attribute) syntax, e.g., "val1.field2" as opposed to "val1['field2']".  The attached patch does this.  It acts like the Python standard method __getattr__ in that it first looks for a predefined attribute (such as "type"), and only if that fails will it look for a value field with the given name.  So val1.type means what it always did (and if you want the "type" field of some structure value, you'd need to use val1['type'] as before).

I don't have write privs, but I do have a copyright assignment in place.

	paul

2011-08-12  Paul Koning  <ni1d@arrl.net>

	* python/py-value.c (valpy_getattr): New function.

Index: python/py-value.c
===================================================================
RCS file: /cvs/src/src/gdb/python/py-value.c,v
retrieving revision 1.25
diff -u -r1.25 py-value.c
--- python/py-value.c	27 Jun 2011 19:21:51 -0000	1.25
+++ python/py-value.c	12 Aug 2011 19:21:26 -0000
@@ -492,6 +492,36 @@
   return res_val ? value_to_value_object (res_val) : NULL;
 }
 
+/* Given string name of an element inside structure, return its value
+   object.  Used for attribute style references.  This one looks for
+   an object element only if the name given isn't a predefined attribute
+   such as "type" or a method such as "dereference".  */
+static PyObject *
+valpy_getattr (PyObject *self, PyObject *key)
+{
+  PyObject *retval;
+  volatile struct gdb_exception except;
+  char *field = NULL;
+
+  retval = PyObject_GenericGetAttr (self, key);
+  if (retval == NULL && PyErr_ExceptionMatches (PyExc_AttributeError))
+    {
+      /* Not a defined attribute, see if it's a value element.  */
+      PyErr_Clear ();
+      retval = valpy_getitem (self, key);
+      if (retval == NULL)
+	{
+	  if (gdbpy_is_string (key))
+	    field = python_string_to_host_string (key);
+	  if (field == NULL)
+	    field = "(none)";
+	  PyErr_Format (PyExc_AttributeError,
+			"'gdb.Value' object has no attribute '%s'", field);
+	}
+    }
+  return retval;
+}
+
 static int
 valpy_setitem (PyObject *self, PyObject *key, PyObject *value)
 {
@@ -1307,7 +1337,7 @@
   valpy_hash,		          /*tp_hash*/
   valpy_call,	                  /*tp_call*/

Re: [Python] Allow attribute references to gdb.Value objects

[Tom Tromey]

>>>>> "Paul" == Paul Koning <paulkoning@comcast.net> writes:

Paul> It would be more natural to be able to reference fields of a
Paul> gdb.Value by the standard field (attribute) syntax, e.g.,
Paul> "val1.field2" as opposed to "val1['field2']".  The attached patch
Paul> does this.  It acts like the Python standard method __getattr__ in
Paul> that it first looks for a predefined attribute (such as "type"),
Paul> and only if that fails will it look for a value field with the
Paul> given name.  So val1.type means what it always did (and if you
Paul> want the "type" field of some structure value, you'd need to use
Paul> val1['type'] as before).

We considered this initially, but decided on the current approach
instead.  The current approach lets us add attributes to Value without
breaking any existing code.

Tom

RE: [Python] Allow attribute references to gdb.Value objects

[Paul_Koning]

That's a fair point, but it comes at the expense of making the code look rather un-Pythonic.  It seems reasonable to offer the option, and document the fact that code that takes advantage of it may be affected by new built-in attributes.

	paul

-----Original Message-----
From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Tom Tromey
Sent: Monday, August 15, 2011 3:10 PM
To: Paul Koning
Cc: gdb-patches@sourceware.org
Subject: Re: [Python] Allow attribute references to gdb.Value objects

>>>>> "Paul" == Paul Koning <paulkoning@comcast.net> writes:

Paul> It would be more natural to be able to reference fields of a 
Paul> gdb.Value by the standard field (attribute) syntax, e.g., 
Paul> "val1.field2" as opposed to "val1['field2']".  The attached patch 
Paul> does this.  It acts like the Python standard method __getattr__ in 
Paul> that it first looks for a predefined attribute (such as "type"), 
Paul> and only if that fails will it look for a value field with the 
Paul> given name.  So val1.type means what it always did (and if you 
Paul> want the "type" field of some structure value, you'd need to use 
Paul> val1['type'] as before).

We considered this initially, but decided on the current approach instead.  The current approach lets us add attributes to Value without breaking any existing code.

Tom

Re: [Python] Allow attribute references to gdb.Value objects

[Tom Tromey]

>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:

Paul> That's a fair point, but it comes at the expense of making the code
Paul> look rather un-Pythonic.  It seems reasonable to offer the option, and
Paul> document the fact that code that takes advantage of it may be affected
Paul> by new built-in attributes.

My reasoning is that we want to encourage robust pretty-printers (a main
use of the value API), and robust code has to use the dictionary syntax.
So, why not just enforce this by only having the dictionary syntax?

Tom

RE: [Python] Allow attribute references to gdb.Value objects

[Paul_Koning]

Sorry about the top posting, that's about all I can do with the unfortunate mail program I have. 

If you want widely used and distributed robust scripts like pretty-printers, yes, indeed.  On the other hand, I also look at the Python scripting machinery as general purpose scripting to do the sort of things done by armies of users -- exactly as the old scripting stuff was used.  There you're dealing with stuff that may be much more ad-hoc, limited in life, easily tweaked if it breaks, a user community that might just be one or two people.  I'm going through that right now -- doing a bunch of scripts to help debug a specific problem.  That code may in fact not even be used again at all after the bug is found, or if it does get used, keeping it working across gdb releases won't be an issue at all.  But writing more natural-feeling Python code is a more important consideration.

	paul

-----Original Message-----
From: Tom Tromey [mailto:tromey@redhat.com] 
Sent: Monday, August 15, 2011 4:43 PM
To: Koning, Paul
Cc: gdb-patches@sourceware.org
Subject: Re: [Python] Allow attribute references to gdb.Value objects

>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:

Paul> That's a fair point, but it comes at the expense of making the 
Paul> code look rather un-Pythonic.  It seems reasonable to offer the 
Paul> option, and document the fact that code that takes advantage of it 
Paul> may be affected by new built-in attributes.

My reasoning is that we want to encourage robust pretty-printers (a main use of the value API), and robust code has to use the dictionary syntax.
So, why not just enforce this by only having the dictionary syntax?

Tom

Re: [Python] Allow attribute references to gdb.Value objects

[Daniel Jacobowitz]

On Mon, Aug 15, 2011 at 4:54 PM,  <Paul_Koning@dell.com> wrote:
> Sorry about the top posting, that's about all I can do with the unfortunate mail program I have.
>
> If you want widely used and distributed robust scripts like pretty-printers, yes, indeed.  On the other hand, I also look at the Python scripting machinery as general purpose scripting to do the sort of things done by armies of users -- exactly as the old scripting stuff was used.  There you're dealing with stuff that may be much more ad-hoc, limited in life, easily tweaked if it breaks, a user community that might just be one or two people.  I'm going through that right now -- doing a bunch of scripts to help debug a specific problem.  That code may in fact not even be used again at all after the bug is found, or if it does get used, keeping it working across gdb releases won't be an issue at all.  But writing more natural-feeling Python code is a more important consideration.

IMO, the robustness choice outweighs this consideration.  While a lot
of these scripts are for a single-purpose session, I'm finding that we
check them in somewhere and adapt them to future bugs.  I'm sure
they'll break in all sorts of interesting ways; I'd rather not add one
that we *know* will end in breakage.

>
>        paul
>
> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Monday, August 15, 2011 4:43 PM
> To: Koning, Paul
> Cc: gdb-patches@sourceware.org
> Subject: Re: [Python] Allow attribute references to gdb.Value objects
>
>>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:
>
> Paul> That's a fair point, but it comes at the expense of making the
> Paul> code look rather un-Pythonic.  It seems reasonable to offer the
> Paul> option, and document the fact that code that takes advantage of it
> Paul> may be affected by new built-in attributes.
>
> My reasoning is that we want to encourage robust pretty-printers (a main use of the value API), and robust code has to use the dictionary syntax.
> So, why not just enforce this by only having the dictionary syntax?
>
> Tom
>



-- 
Thanks,
Daniel

RE: [Python] Allow attribute references to gdb.Value objects

[Paul_Koning]

> IMO, the robustness choice outweighs this consideration.  While a lot of these scripts are for a single-purpose session, I'm finding that we check them in somewhere and adapt them to future bugs.  I'm sure they'll break in all sorts of interesting ways; I'd rather not add one that we *know* will end in breakage.

Ok, I guess I'll drop the idea, and rewrite my own scripts accordingly.

	paul