From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29238 invoked by alias); 7 Jul 2008 23:44:47 -0000 Received: (qmail 29228 invoked by uid 22791); 7 Jul 2008 23:44:46 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 Jul 2008 23:44:29 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m67NiOrD024469; Mon, 7 Jul 2008 19:44:24 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m67NiOQx001531; Mon, 7 Jul 2008 19:44:24 -0400 Received: from opsy.redhat.com (vpn-10-112.bos.redhat.com [10.16.10.112]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m67NiNMp026427; Mon, 7 Jul 2008 19:44:24 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 406C33781A0; Mon, 7 Jul 2008 17:44:23 -0600 (MDT) To: Thiago Jung Bauermann Cc: gdb-patches@sourceware.org Subject: Re: [RFC][patch 2/9] export values mechanism to Python References: <20080429155212.444237503@br.ibm.com> <20080429155304.466637516@br.ibm.com> <20080528212451.GB2969@caradoc.them.org> <1215410598.1795.58.camel@localhost.localdomain> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Mon, 07 Jul 2008 23:44:00 -0000 In-Reply-To: <1215410598.1795.58.camel@localhost.localdomain> (Thiago Jung Bauermann's message of "Mon\, 07 Jul 2008 03\:03\:17 -0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00102.txt.bz2 >>>>> "Thiago" == Thiago Jung Bauermann writes: Thiago> In the GDB BoF we decided to use Python __magic__ for gdb.Values, so I Thiago> started working on it. My idea is to make them behave as much as the Thiago> corresponding native Python types as possible, so a gdb.Value with an Thiago> int type would behave like a Python int. BTW -- there is some redundancy between gdbpy_make_value and convert_value_from_python. It seems to me that we should have a single function to convert a PyObject* to a 'struct value *', and then a separate function to box a 'struct value *' in a gdb.Value. Also, I think we don't need gdb.make_value. It seems to me that this should instead be a gdb.Value constructor. What do you think? (Really this constructor needs a Type argument, but we haven't implemented that yet...) FWIW, gdb.Function does default conversions of python objects to gdb values. I.e., if the python function does 'return 5', that is turned into a struct value whose type is some default int type. So, in most cases I think we won't need to make new Value objects at all -- any place one is needed I think we can easily accept ordinary Python objects as well. Thiago> In the case of valpy_get_element (which is used to access an element in Thiago> a value representing a struct or class), using __getitem__ means that in Thiago> Python one would use a_struct["element"] to access a_struct.element. Thiago> This looks a bit strange at least. I don't mind this, my reasoning is: * I suspect it will be more common to use a string-valued expression here than it will be to use a string constant. * This approach also works nicely for arrays. * This approach does not mix the Value namespace with the debuggee's field names. Thiago> If Python supports class methods (I'm not sure of that, but I Thiago> think it does), then we could have things like Thiago> gdb.Values.some_method (value_object, other, args). I definitely do not like the idea of class methods that are really instance methods in disguise. Tom