Why do functions objfpy_new and pspy_new exist?
Wed Oct 1 18:10:00 GMT 2014
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.
More information about the Gdb-patches