Re: [RFC][patch 2/9] export values mechanism to Python

[Tom Tromey <tromey@redhat.com>]

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:

Thiago> In the GDB BoF we decided to use Python __magic__ for gdb.Values, so I
Thiago> started working on it. My idea is to make them behave as much as the
Thiago> corresponding native Python types as possible, so a gdb.Value with an
Thiago> int type would behave like a Python int.

BTW -- there is some redundancy between gdbpy_make_value and
convert_value_from_python.  It seems to me that we should have a
single function to convert a PyObject* to a 'struct value *',
and then a separate function to box a 'struct value *' in a
gdb.Value.

Also, I think we don't need gdb.make_value.  It seems to me that this
should instead be a gdb.Value constructor.  What do you think?
(Really this constructor needs a Type argument, but we haven't
implemented that yet...)

FWIW, gdb.Function does default conversions of python objects to gdb
values.  I.e., if the python function does 'return 5', that is turned
into a struct value whose type is some default int type.  So, in most
cases I think we won't need to make new Value objects at all -- any
place one is needed I think we can easily accept ordinary Python
objects as well.

Thiago> In the case of valpy_get_element (which is used to access an element in
Thiago> a value representing a struct or class), using __getitem__ means that in
Thiago> Python one would use a_struct["element"] to access a_struct.element.
Thiago> This looks a bit strange at least.

I don't mind this, my reasoning is:

* I suspect it will be more common to use a string-valued expression
  here than it will be to use a string constant.
* This approach also works nicely for arrays.
* This approach does not mix the Value namespace with the
  debuggee's field names.

Thiago> If Python supports class methods (I'm not sure of that, but I
Thiago> think it does), then we could have things like
Thiago> gdb.Values.some_method (value_object, other, args).

I definitely do not like the idea of class methods that are really
instance methods in disguise.

Tom