From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29559 invoked by alias); 4 Nov 2011 20:41:03 -0000 Received: (qmail 29551 invoked by uid 22791); 4 Nov 2011 20:41:02 -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 qmta08.westchester.pa.mail.comcast.net (HELO qmta08.westchester.pa.mail.comcast.net) (76.96.62.80) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Nov 2011 20:40:47 +0000 Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta08.westchester.pa.mail.comcast.net with comcast id t8bA1h0030EZKEL588gnhK; Fri, 04 Nov 2011 20:40:47 +0000 Received: from [192.168.10.125] ([24.218.185.35]) by omta01.westchester.pa.mail.comcast.net with comcast id t8gn1h00J0mEv9C3M8gnSM; Fri, 04 Nov 2011 20:40:47 +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: Fri, 04 Nov 2011 20:41:00 -0000 Cc: Eli Zaretskii , tromey@redhat.com, gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <37B202A1-DCD5-423E-8E30-55A6F2BE21EF@comcast.net> References: <3A3AF5AE-70E8-43D0-B8CE-DCADFEEF879A@comcast.net> <560557F2-1B8B-4633-8CD6-E63705EEAF0E@comcast.net> <83wrckrcg1.fsf@gnu.org> 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/msg00122.txt.bz2 On Nov 4, 2011, at 1:41 PM, Doug Evans wrote: > On Tue, Oct 4, 2011 at 8:56 AM, Paul Koning wrot= e: >>=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. Entries = for >>>>> documentation have to go there. >>>>=20 >>>> I overlooked that file. Thanks for the reference. Should I move the = 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 exceptio= n. >=20 > OTOH, adding the new support to the result of gdb.Type.fields() is great. >=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. Part of my reasoning is to have gdb.Value and gdb.Type look alike. gdb.Val= ue always had field lookup by name, i.e., it behaves like a Python dictiona= ry. So I wanted to make the same apply to gdb.Type since the analogy seeme= d obvious. And in both cases, I wanted the normal Python dict methods to b= e 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. paul