From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31189 invoked by alias); 25 Sep 2014 10:09:19 -0000 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 Received: (qmail 31179 invoked by uid 89); 25 Sep 2014 10:09:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 25 Sep 2014 10:09:17 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8PA9DAp029725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 25 Sep 2014 06:09:13 -0400 Received: from localhost.localdomain (ovpn-112-17.ams2.redhat.com [10.36.112.17]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8PA9B7h008416; Thu, 25 Sep 2014 06:09:12 -0400 Message-ID: <5423E9C7.3060202@redhat.com> Date: Thu, 25 Sep 2014 10:09:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: gdb-patches@sourceware.org, Doug Evans Subject: Re: Why do functions objfpy_new and pspy_new exist? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00726.txt.bz2 On 24/09/14 22:38, Doug Evans wrote: > Hi. > > Normally, python wrappers of gdb objects are created with a > foo_to_foo_object function. > E.g., objfile_to_objfile_object and pspace_to_pspace_object. > > So why do objfpy_new and pspy_new exist? > [defined in py-objfile.c and py-progspace.c respectively] > > IOW, when would one ever usefully do something with > foo_objfile = gdb.Objfile() > or > foo_pspace = gdb.Progspace() I can't think of a reason. But someone else might. Anyway the point is moot (unfortunately) as we have an API promise, so they get to stay. Forever. > ? > > This question applies to pretty much every gdb object that can be > wrapped by Python. I can imagine maybe a few objects where it would > be useful to create non-gdb-wrapped python objects of some type. > But I'd expect such cases to be rare. > > Am I missing something? I don't mind cleaning up the actual "new object" code, but the calls must remain. However we re-factor internally, the API must not loose functionality. (I am in effect, stating this "as obvious" for the lists and archives in case it comes up again. I am sure you already knew about it ;) > > I ask because we've got some duplicated code, two copies of the > gdb.Objfile and gdb.Progspace constructors > (objfpy_new + objfile_to_objfile_object, > and pspy_new + pspace_to_pspace_object), > and I think some cleanup is in order. Being a pedant here, but this really should have gone to gdb@sourceware? I personally prefer design decisions to be discussed on that list. gdb-patches@ is far too high in traffic and stuff might get missed. Cheers, Phil