This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Python API Retention Policy [was Re: [RFC] Python's gdb.FRAME_UNWIND_NULL_ID is no longer used. What to do with it?]
- From: Tom Tromey <tromey at redhat dot com>
- To: Doug Evans <xdje42 at gmail dot com>
- Cc: Phil Muldoon <pmuldoon at redhat dot com>, Pedro Alves <palves at redhat dot com>, gdb-patches at sourceware dot org
- Date: Wed, 11 Dec 2013 13:54:02 -0700
- Subject: Re: 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
- References: <CAP9bCMRS-MM1pwucyUaVArY0G+X7-db82XWc3GUsVE823Ro7-A at mail dot gmail dot com>
Doug> It would also be nice to be able to add something that's not "fully baked"
Doug> without having to promise to keep it forever.
Doug> Can the module system help here?
Doug> E.g. can we have gdb.experimental and gdb.deprecated modules?
Doug> [with associated _ versions for the C side I guess]
I'm not totally opposed to it but I am skeptical.
I think it's hard to actually remove things, regardless of how one marks
them. Roll out of any change -- either deletion or promotion -- is
difficult.
I find it hard to discuss this in the abstract. Is there some
particular addition you want to add as experimental?
Doug> Another way to go I suppose is to add version numbers to the API
Doug> (and maybe have gdb without a version number always be the latest).
I don't understand how this solves the problem of accumulating unwanted
baggage.
Doug> I wonder what other projects that use python do.
Prior art in a similar situation could be convincing.
Tom