From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14965 invoked by alias); 2 Aug 2008 17:38:07 -0000 Received: (qmail 14957 invoked by uid 22791); 2 Aug 2008 17:38:06 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 02 Aug 2008 17:37:47 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 2FB5E98397; Sat, 2 Aug 2008 17:37:45 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id E68249835A; Sat, 2 Aug 2008 17:37:44 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KPL32-0002m2-15; Sat, 02 Aug 2008 13:37:44 -0400 Date: Sat, 02 Aug 2008 17:38:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii , Tom Tromey Cc: bauerman@br.ibm.com, gdb-patches@sourceware.org Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support Message-ID: <20080802173744.GA10333@caradoc.them.org> Mail-Followup-To: Eli Zaretskii , Tom Tromey , bauerman@br.ibm.com, gdb-patches@sourceware.org References: <1216245620.12209.18.camel@localhost.localdomain> <20080718195010.GA14356@caradoc.them.org> <1216653969.31797.6.camel@localhost.localdomain> <20080726182957.GA12363@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2008-05-11) 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-08/txt/msg00028.txt.bz2 On Sat, Jul 26, 2008 at 10:24:49PM +0300, Eli Zaretskii wrote: > > What would you like explained? > > Why it is important to the manual reader to know that there's a module > called `gdb', and that all methods and classes added by GDB are placed > in that module. Suppose I didn't know that--what would I be missing > as result, and what code would I get wrong? You would not know that you had to 'import gdb' in any new modules you wrote, that's all. This is obvious to a Python programmer from the existence of the module. Tom, the gdb module is automatically imported in executed Python fragments, right? That may be worth an explicit mention. On Fri, Aug 01, 2008 at 02:04:19PM -0600, Tom Tromey wrote: > >>>>> "Daniel" == Daniel Jacobowitz writes: > > [ gdb.show ] > Daniel> I suggest "get" parallel to "set", then. > > I've been thinking about this, and on further reflection I think both > "show" and "get" are too generic. How about "get_parameter"? I > picked this because the manual refers to these entities as parameters > at one point: > > @kindex info set > To display all the settable parameters and their current > values, you can use @code{show} with no arguments; you may also use This sounds good. > [ flush and write ] > Daniel> Maybe we should move it to a new module gdb._internal then. > Daniel> Tom, what do you think? > > I'm ambivalent about it. I don't see much harm in exposing and > documenting these primitives. If it is what you want, though, I will > do it. I suppose the wrapper class ought to go in _internal as well. I'm happy to leave them where they are and document them. How about replacing this: > +Print a string to @value{GDBN}'s paginated standard output stream. > +Ordinarily your program should not call this function directly; simply > +print to @code{sys.stdout} as usual. with: Print a string to @value{GDBN}'s paginated standard output stream. Writing to @code{sys.stdout} will automatically call this method. -- Daniel Jacobowitz CodeSourcery