Re: Why do functions objfpy_new and pspy_new exist?

[Doug Evans <dje at google 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.