This is the mail archive of the gdb-patches@sourceware.org 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]

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


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


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