From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26667 invoked by alias); 13 Mar 2008 14:16:56 -0000 Received: (qmail 26654 invoked by uid 22791); 13 Mar 2008 14:16:55 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Mar 2008 14:16:29 +0000 Received: from mailhub3.br.ibm.com (unknown [9.18.232.110]) by igw3.br.ibm.com (Postfix) with ESMTP id 8921F390272 for ; Thu, 13 Mar 2008 11:05:08 -0300 (BRST) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m2DEGPXw3760202 for ; Thu, 13 Mar 2008 11:16:25 -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 m2DEGPmU029686 for ; Thu, 13 Mar 2008 11:16:25 -0300 Received: from [9.18.238.95] ([9.18.238.95]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m2DEGPsL029677; Thu, 13 Mar 2008 11:16:25 -0300 Subject: Re: [RFC] Strings and arrays without malloc From: Thiago Jung Bauermann To: Tom Tromey Cc: gdb-patches@sourceware.org In-Reply-To: References: <20080309161335.GA26917@caradoc.them.org> Content-Type: text/plain Date: Thu, 13 Mar 2008 14:16:00 -0000 Message-Id: <1205417784.6643.78.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 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-03/txt/msg00143.txt.bz2 On Wed, 2008-03-12 at 23:19 -0600, Tom Tromey wrote: > my current thinking is that the general approach > should be to write a thin binding, and then add a nicer OO API in pure > python. I'm not a python person though, so maybe this is weird. I see two possible approaches here: 1. Yours: expose a procedural layer to python, and build an OO API on top of it, using Python itself. This has the advantage of keeping the C <-> Python glue simple, but you would have to maintain code in two languages (maybe not a problem). 2. Create new types (using Python's C API) to represent the classes we want to expose to Python. All of the implementation would be in C, then. The glue would be more complicated (but maybe not much more complicated), but then the implementation is all in one language, and in one place. Last night I started to experiment creating an OO API for values, using Volodya's branch. I chose to use approach 2, but I didn't really make my mind yet. If it turns out that it really isn't much more complicated than 1, then I think I prefer to have it all in one language. > Opinions, advice, encouragement, etc ... all welcome. At times I > suspect that nobody is reading this. I think there are lots of eyes on this Python support thing, including mine. :-) I'm starting to put some hands on it too, FWIW. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center