From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10273 invoked by alias); 3 Jun 2008 00:19:24 -0000 Received: (qmail 10263 invoked by uid 22791); 3 Jun 2008 00:19:23 -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; Tue, 03 Jun 2008 00:19:06 +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 m530J19O012240; Mon, 2 Jun 2008 20:19:01 -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 m530J1cl000979; Mon, 2 Jun 2008 20:19:01 -0400 Received: from opsy.redhat.com (vpn-10-38.bos.redhat.com [10.16.10.38]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m530J04S029280; Mon, 2 Jun 2008 20:19:01 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id EAF78508238; Mon, 2 Jun 2008 18:18:59 -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> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Tue, 03 Jun 2008 00:19:00 -0000 In-Reply-To: <20080528212451.GB2969@caradoc.them.org> (Daniel Jacobowitz's message of "Wed\, 28 May 2008 17\:24\:51 -0400") 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-06/txt/msg00011.txt.bz2 >>>>> "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. Also, about the varobj patch in particular: I notice that it is MI-specific. At least for type visualizers I think I would like something that works with 'print' as well. I'm thinking: * A way to register a type->object mapping from Python * A new method on the Python object (if needed -- I'm not an expert in this area) to return the 'print' form of the value. (If a new method is needed this, I think, implies that we should not use __str__ here.) * Modifications to 'print' and friends * A new 'raw' format to print to let us bypass the custom printer and just show whatever the language defaults to. Let me know what you think of this general plan. Tom