From: Paul Koning <paulkoning@comcast.net>
To: Doug Evans <dje@google.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
tromey@redhat.com, gdb-patches@sourceware.org
Subject: Re: [RFA] Re: Python: add field access by name and standard python mapping methods to gdb.Type
Date: Sat, 05 Nov 2011 14:36:00 -0000 [thread overview]
Message-ID: <A9355A24-C061-4120-AEA0-A13D8F1A9FE8@comcast.net> (raw)
In-Reply-To: <CADPb22T7ZbU0KPgnw8E-vce+=O+iR4HdF3E86rJZGmLvHo5szg@mail.gmail.com>
On Nov 4, 2011, at 7:04 PM, Doug Evans wrote:
> 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.
Quite right.
>
> 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?]
Yes, and that's part of what I intend to propose.
>
> Maybe I'd be happy if gdb.Type (and maybe gdb.Value) were simply more
> rigorous in throwing exceptions for invalid cases.
I agree. I'll put that together.
paul
next prev parent reply other threads:[~2011-11-05 14:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-16 4:09 Paul Koning
2011-09-16 7:36 ` Eli Zaretskii
2011-09-16 10:47 ` Phil Muldoon
2011-09-16 14:57 ` Paul Koning
2011-09-16 14:57 ` Phil Muldoon
2011-09-16 15:41 ` Paul Koning
2011-09-23 17:21 ` Doug Evans
2011-09-26 17:15 ` [RFA] " Paul Koning
2011-09-28 19:25 ` Doug Evans
2011-09-28 20:41 ` Paul Koning
2011-10-04 15:14 ` Tom Tromey
2011-10-04 15:30 ` Paul Koning
2011-10-04 15:42 ` Eli Zaretskii
2011-10-04 15:56 ` Paul Koning
2011-11-04 17:42 ` Doug Evans
2011-11-04 20:41 ` Paul Koning
2011-11-04 23:05 ` Doug Evans
2011-11-05 14:36 ` Paul Koning [this message]
2011-11-05 21:04 ` Doug Evans
2011-11-08 21:40 ` [RFA] Python: raise exception on field-related gdb.Type methods if it's not struct or union Paul Koning
2011-11-09 0:29 ` Doug Evans
2011-11-09 1:53 ` Paul Koning
2011-11-09 18:10 ` Paul Koning
2011-11-15 19:01 ` [PING] " Paul Koning
2011-11-15 20:57 ` Doug Evans
2011-11-15 21:21 ` Paul Koning
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A9355A24-C061-4120-AEA0-A13D8F1A9FE8@comcast.net \
--to=paulkoning@comcast.net \
--cc=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox