From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8215 invoked by alias); 5 Nov 2011 14:36:51 -0000 Received: (qmail 7939 invoked by uid 22791); 5 Nov 2011 14:36:49 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta07.emeryville.ca.mail.comcast.net (HELO qmta07.emeryville.ca.mail.comcast.net) (76.96.30.64) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Nov 2011 14:36:34 +0000 Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta07.emeryville.ca.mail.comcast.net with comcast id tSWx1h00317UAYkA7ScTnQ; Sat, 05 Nov 2011 14:36:27 +0000 Received: from [192.168.10.125] ([24.218.185.35]) by omta13.emeryville.ca.mail.comcast.net with comcast id tSb71h00T0mEv9C8ZSb80U; Sat, 05 Nov 2011 14:35:09 +0000 Subject: Re: [RFA] Re: Python: add field access by name and standard python mapping methods to gdb.Type Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Koning In-Reply-To: Date: Sat, 05 Nov 2011 14:36:00 -0000 Cc: Eli Zaretskii , tromey@redhat.com, gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A3AF5AE-70E8-43D0-B8CE-DCADFEEF879A@comcast.net> <560557F2-1B8B-4633-8CD6-E63705EEAF0E@comcast.net> <83wrckrcg1.fsf@gnu.org> <37B202A1-DCD5-423E-8E30-55A6F2BE21EF@comcast.net> To: Doug Evans Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00129.txt.bz2 On Nov 4, 2011, at 7:04 PM, Doug Evans wrote: > On Fri, Nov 4, 2011 at 1:40 PM, Paul Koning wrot= e: >>=20 >> On Nov 4, 2011, at 1:41 PM, Doug Evans wrote: >>=20 >>> On Tue, Oct 4, 2011 at 8:56 AM, Paul Koning wr= ote: >>>>=20 >>>> On Oct 4, 2011, at 11:41 AM, Eli Zaretskii wrote: >>>>=20 >>>>>> From: Paul Koning >>>>>> Date: Tue, 4 Oct 2011 11:29:58 -0400 >>>>>> Cc: Doug Evans , gdb-patches@sourceware.org >>>>>>=20 >>>>>>=20 >>>>>>> For future reference, there is a separate ChangeLog in doc. Entrie= s for >>>>>>> documentation have to go there. >>>>>>=20 >>>>>> I overlooked that file. Thanks for the reference. Should I move th= e entry there? >>>>>=20 >>>>> Yes, please. >>>>=20 >>>> Done. >>>>=20 >>>>>=20 >>>>>>> Could you write a NEWS entry for this change? >>>>>>=20 >>>>>> How about this? >>>>>=20 >>>>> Fine with me, thanks. >>>>=20 >>>> Committed. >>>=20 >>> 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. >>>=20 >>> 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) =3D=3D 0. >>> IOW, len(gdb.Type of "int") is now 0. I think it should flag an except= ion. >>>=20 >>> OTOH, adding the new support to the result of gdb.Type.fields() is grea= t. >>>=20 >>> 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. >>=20 >> 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 dicti= onary. >=20 > For structs and such sure, but not so for scalars. > Scalars shouldn't behave like a dictionary. Quite right. >=20 > 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. >=20 > 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