This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Re: Python: add field access by name and standard python mapping methods to gdb.Type
- From: Doug Evans <dje at google dot com>
- To: Paul Koning <paulkoning at comcast dot net>
- Cc: Eli Zaretskii <eliz at gnu dot org>, tromey at redhat dot com, gdb-patches at sourceware dot org
- Date: Fri, 4 Nov 2011 16:04:44 -0700
- Subject: Re: [RFA] Re: Python: add field access by name and standard python mapping methods to gdb.Type
- References: <A3E6FC3B-1E11-4F34-817E-897C74B2A669@comcast.net> <m3hb4c935j.fsf@redhat.com> <3A3AF5AE-70E8-43D0-B8CE-DCADFEEF879A@comcast.net> <CADPb22RTizsTBzTHQ6SZbsW_sv7FNCZD6EQeLacNWtAWNRcZWQ@mail.gmail.com> <F08522DE-7678-410E-92E5-2692482305AF@comcast.net> <CADPb22SrXdBoU5KRjDJ8aox=ne9pV9Sht1qemgkC_LaOLjK51w@mail.gmail.com> <560557F2-1B8B-4633-8CD6-E63705EEAF0E@comcast.net> <m3ipo4rdqj.fsf@fleche.redhat.com> <A986D29F-2D94-4F36-9135-64C00C5F48A3@comcast.net> <83wrckrcg1.fsf@gnu.org> <CA5083E5-DE1A-404F-B68C-76AB65F62E83@comcast.net> <CADPb22RSiVqCj3USYBw=Bbi88=mi_HtZSPSAwJO61-JR8POP8w@mail.gmail.com> <37B202A1-DCD5-423E-8E30-55A6F2BE21EF@comcast.net>
On Fri, Nov 4, 2011 at 1:40 PM, Paul Koning <paulkoning@comcast.net> wrote:
>
> On Nov 4, 2011, at 1:41 PM, Doug Evans wrote:
>
>> On Tue, Oct 4, 2011 at 8:56 AM, Paul Koning <paulkoning@comcast.net> wrote:
>>>
>>> On Oct 4, 2011, at 11:41 AM, Eli Zaretskii wrote:
>>>
>>>>> From: Paul Koning <paulkoning@comcast.net>
>>>>> Date: Tue, 4 Oct 2011 11:29:58 -0400
>>>>> Cc: Doug Evans <dje@google.com>, gdb-patches@sourceware.org
>>>>>
>>>>>
>>>>>> For future reference, there is a separate ChangeLog in doc. ?Entries for
>>>>>> documentation have to go there.
>>>>>
>>>>> I overlooked that file. ?Thanks for the reference. ?Should I move the entry there?
>>>>
>>>> Yes, please.
>>>
>>> Done.
>>>
>>>>
>>>>>> Could you write a NEWS entry for this change?
>>>>>
>>>>> How about this?
>>>>
>>>> Fine with me, thanks.
>>>
>>> Committed.
>>
>> Ummm, hi.
>> I know I looked at the patch and approved it myself, but having played
>> with it for awhile I'm having second thoughts.
>> And before a release goes out I'd like to get this resolved.
>> If you want I'll do the work, or at least help however I can.
>>
>> One way to look at my reasoning is that a type "has a" field list but
>> it's not the case that a type "is a" field list.
>> And I'm uncomfortable with len(gdb.parse_and_eval("1").type) == 0.
>> IOW, len(gdb.Type of "int") is now 0. ?I think it should flag an exception.
>>
>> OTOH, adding the new support to the result of gdb.Type.fields() is great.
>>
>> Anyone object to me changing things and moving the new iterator
>> support to gdb.Type.fields()?
>> Or do people disagree with my reasoning?
>> I haven't looked into what's involved. ?At this point I just want to
>> get the user-visible semantics right.
>
> Part of my reasoning is to have gdb.Value and gdb.Type look alike. ?gdb.Value always had field lookup by name, i.e., it behaves like a Python dictionary.
For structs and such sure, but not so for scalars.
Scalars shouldn't behave like a dictionary.
If we're going for consistency between gdb.Value and gdb.Type then for
structs and such we'll need len(gdb.Value) to return the number of
fields. [Right?]
Maybe I'd be happy if gdb.Type (and maybe gdb.Value) were simply more
rigorous in throwing exceptions for invalid cases.
> So I wanted to make the same apply to gdb.Type since the analogy seemed obvious. ?And in both cases, I wanted the normal Python dict methods to be available. ?(For gdb.Value, that's not submitted yet.)
>
> In my view, gdb.Type.fields remains as a backward compatibility synonym for gdb.Type.values (the standard dict method).
>
> I do agree that having len() return 0 instead of an error seems wrong.
That could be fixed by having typy_length throw an appropriate error
for scalars, etc.