Re: Why do functions objfpy_new and pspy_new exist?

[Phil Muldoon <pmuldoon at redhat dot com>]

On 25/09/14 23:07, Doug Evans wrote:
>>
>>
>> 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.

That sounds like a plausible plan.  The next step is documenting it in
the wiki and/or other places.

Cheers

Phil