This is the mail archive of the
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> <firstname.lastname@example.org> <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> <email@example.com> <A986D29F-2D94-4F36-9135-64C00C5F48A3@comcast.net> <firstname.lastname@example.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 <email@example.com> wrote:
> On Nov 4, 2011, at 1:41 PM, Doug Evans wrote:
>> On Tue, Oct 4, 2011 at 8:56 AM, Paul Koning <firstname.lastname@example.org> wrote:
>>> On Oct 4, 2011, at 11:41 AM, Eli Zaretskii wrote:
>>>>> From: Paul Koning <email@example.com>
>>>>> Date: Tue, 4 Oct 2011 11:29:58 -0400
>>>>> Cc: Doug Evans <firstname.lastname@example.org>, email@example.com
>>>>>> 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.
>>>>>> Could you write a NEWS entry for this change?
>>>>> How about this?
>>>> Fine with me, thanks.
>> 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
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.