This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Python API Retention Policy [was Re: [RFC] Python's gdb.FRAME_UNWIND_NULL_ID is no longer used. What to do with it?]
- From: Doug Evans <xdje42 at gmail dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: Pedro Alves <palves at redhat dot com>, gdb-patches at sourceware dot org
- Date: Fri, 29 Nov 2013 09:22:30 -0800
- Subject: Python API Retention Policy [was Re: [RFC] Python's gdb.FRAME_UNWIND_NULL_ID is no longer used. What to do with it?]
- Authentication-results: sourceware.org; auth=none
On Thu, Nov 28, 2013 at 1:16 PM, Phil Muldoon <pmuldoon@redhat.com> wrote:
> It might be time to think about what the API pertains too. GDB
> evolves constantly, and I really don't want Python in a few years from
> now to be full of deprecated functions/constants.
IWBN to have the ability to phase things out and ultimately delete them.
Otherwise we grow increasing baggage that slows us down.
It would also be nice to be able to add something that's not "fully baked"
without having to promise to keep it forever.
Can the module system help here?
E.g. can we have gdb.experimental and gdb.deprecated modules?
[with associated _ versions for the C side I guess]
Another way to go I suppose is to add version numbers to the API
(and maybe have gdb without a version number always be the latest).
We could have a policy for how long we promise to keep something "old"
(either deprecated or in an earlier API version) before we're free to
delete it.
I wonder what other projects that use python do.