From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9612 invoked by alias); 25 Sep 2014 22:07:25 -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 9598 invoked by uid 89); 25 Sep 2014 22:07:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f175.google.com Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 25 Sep 2014 22:07:23 +0000 Received: by mail-vc0-f175.google.com with SMTP id hy4so1186957vcb.34 for ; Thu, 25 Sep 2014 15:07:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9i8jrCFaGrhxN1nCPGxlHAf2V7yMl3laSwNR5LoPY5o=; b=lwIcdT23bh0NEUCzhW8C5YOeBY4N0V/0T6NBjCXoWV0UYJUhR0be1CemX2RLlRPWFS Qiarq0Yj7j6t237kbj/LMfFCCgPc0pqi7YQtvt8Y5CEY7Dnw6mjGnZu40zrJ4bfp7nLI zZPI8btFGUefnk+seiiIYBTJZmZT0sCHqA7MyJCV7cuRe3p+3X5Nm1aGAkScHZg3Nil3 /DFe+Y6RzEcK7/2RHvNJHVWVryPzklxRKlKPuXPFd0HzEgh3ZsuowgB/N5oFyaSUB+Jl NpyV1OOeGQpG78bsS1Jti0jO45cOu67VEc0EaxFAbB7T+DEMAvwUHVfI/caQI7aFsLPw Y1ng== X-Gm-Message-State: ALoCoQk31ATHG0aOUNifJYOhbTVmELNUqdsWJ42SWMR4w2LQVSbPt33OVTSCUjNXsM1cnb+21ZVa MIME-Version: 1.0 X-Received: by 10.220.172.8 with SMTP id j8mr2337129vcz.32.1411682841180; Thu, 25 Sep 2014 15:07:21 -0700 (PDT) Received: by 10.52.181.65 with HTTP; Thu, 25 Sep 2014 15:07:21 -0700 (PDT) In-Reply-To: <54248505.7030809@redhat.com> References: <5423E9C7.3060202@redhat.com> <54248505.7030809@redhat.com> Date: Thu, 25 Sep 2014 22:07:00 -0000 Message-ID: Subject: Re: Why do functions objfpy_new and pspy_new exist? From: Doug Evans To: Phil Muldoon Cc: Paul Koning , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00753.txt.bz2 On Thu, Sep 25, 2014 at 3:11 PM, Phil Muldoon wrote: > On 25/09/14 16:18, Paul_Koning@dell.com wrote: >> >> On Sep 25, 2014, at 6:09 AM, Phil Muldoon wrote: >> >>> 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. >> >> I would usually agree, but I would make an exception if the API function in question does not produce anything that can be used for any plausible purpose. That may be the case here. > > > I really don't disagree with you Paul. But we have to prove > plausible, and perhaps wait until someone turns up and says "oh I have > this plausible scenario". Perhaps a patch to gdb-patches and a > suitable wait is OK, (though I am not sure GDB Python users read that > list). It is, trust me, a frequent frustration for me to add > yet-another-keyword-while-preserving-original-behavior, especially > with the Python 2.x and 3.x as well. It is, I think, becoming > impossible to manage. > > I don't have an objection beyond does this break the API promise. > That's all I care about. I did not make that promise -- these > decisions were made before my time. But I think we should uphold it. > Maybe if GDB future releases requires only Python 3.x in future we can > amend that. I know I've mentioned this before, but since the topic has come up again, I think GDB could have a formal deprecation process that would allow us to remove things we'd like to remove (this is for API-like things which are harder to remove than, e.g., outdated ports). For the case at hand, as a strawman proposal, what if we add to 7.9 a proposal to remove the non-useful functionality with a note saying that if no one presents a compelling case for keeping it then it will be removed 5 releases later (or some such). 2.5 years feels long enough for this. I can imagine choosing a longer or short amount of time depending on what's being deprecated. The point is there's a process and we use it to clean up GDB. [This is simpler than the general one I have in mind. I'm just throwing out the idea to see if it sticks. :-)] Also, we could have a moratorium on adding more tp_new methods that don't have a use-case. That we can do today.