This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Why do functions objfpy_new and pspy_new exist?
- From: Doug Evans <dje at google dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: Paul Koning <Paul_Koning at dell dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Thu, 25 Sep 2014 16:07:21 -0600
- Subject: Re: Why do functions objfpy_new and pspy_new exist?
- Authentication-results: sourceware.org; auth=none
- References: <yjt2fvfgr95t dot fsf at ruffy dot mtv dot corp dot google dot com> <5423E9C7 dot 3060202 at redhat dot com> <E3798679-04DA-48B8-8E53-5296A54A3528 at dell dot com> <54248505 dot 7030809 at redhat dot com>
On Thu, Sep 25, 2014 at 3:11 PM, Phil Muldoon <pmuldoon@redhat.com> wrote:
> On 25/09/14 16:18, Paul_Koning@dell.com wrote:
>>
>> On Sep 25, 2014, at 6:09 AM, Phil Muldoon <pmuldoon@redhat.com> 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.