From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17017 invoked by alias); 7 Jul 2008 06:03:40 -0000 Received: (qmail 17008 invoked by uid 22791); 7 Jul 2008 06:03:39 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 Jul 2008 06:03:18 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw1.br.ibm.com (Postfix) with ESMTP id 2809032C07D for ; Mon, 7 Jul 2008 02:36:21 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6763JQc2355486 for ; Mon, 7 Jul 2008 03:03:19 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6763ECr004663 for ; Mon, 7 Jul 2008 03:03:14 -0300 Received: from [9.18.200.36] ([9.18.200.36]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6763ETC004660; Mon, 7 Jul 2008 03:03:14 -0300 Subject: Re: [RFC][patch 2/9] export values mechanism to Python From: Thiago Jung Bauermann To: tromey@redhat.com Cc: gdb-patches@sourceware.org In-Reply-To: References: <20080429155212.444237503@br.ibm.com> <20080429155304.466637516@br.ibm.com> <20080528212451.GB2969@caradoc.them.org> Content-Type: text/plain Date: Mon, 07 Jul 2008 06:03:00 -0000 Message-Id: <1215410598.1795.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2008-07/txt/msg00079.txt.bz2 On Mon, 2008-06-02 at 18:18 -0600, Tom Tromey wrote: > >>>>> "Daniel" == Daniel Jacobowitz writes: > > Daniel> Would it be helpful or confusing to automatically expose this > Daniel> as [] in Python, __getitem__? > > Good question. > > In general I've been using explicit method names, like get_* and > set_*. But perhaps we should be using attributes and various > "intrinsic" names... I'm not enough of a Python expert to know what is > preferred. In the GDB BoF we decided to use Python __magic__ for gdb.Values, so I started working on it. My idea is to make them behave as much as the corresponding native Python types as possible, so a gdb.Value with an int type would behave like a Python int. There's one case which I'd like to discuss, and about which I talked to Tromey on IRC: In the case of valpy_get_element (which is used to access an element in a value representing a struct or class), using __getitem__ means that in Python one would use a_struct["element"] to access a_struct.element. This looks a bit strange at least. It would be possible to make this case work more like a real struct, by intercepting python object accesses to attributes. Then one could have a_struct.element work for gdb.Values. The downside is that it means that value objects couldn't have methods since they would be interpreted as struct elements. If Python supports class methods (I'm not sure of that, but I think it does), then we could have things like gdb.Values.some_method (value_object, other, args). Also, Python's own attributes and methods (like __doc__) would clash with structure elements. What do you prefer? -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center