This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Python API Retention Policy [was Re: [RFC] Python's gdb.FRAME_UNWIND_NULL_ID is no longer used. What to do with it?]

On Thu, Nov 28, 2013 at 1:16 PM, Phil Muldoon <> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]