* Python API Retention Policy [was Re: [RFC] Python's gdb.FRAME_UNWIND_NULL_ID is no longer used. What to do with it?]
@ 2013-11-29 19:42 Doug Evans
2013-12-11 20:54 ` Tom Tromey
0 siblings, 1 reply; 2+ messages in thread
From: Doug Evans @ 2013-11-29 19:42 UTC (permalink / raw)
To: Phil Muldoon; +Cc: Pedro Alves, gdb-patches
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Python API Retention Policy [was Re: [RFC] Python's gdb.FRAME_UNWIND_NULL_ID is no longer used. What to do with it?]
2013-11-29 19:42 Python API Retention Policy [was Re: [RFC] Python's gdb.FRAME_UNWIND_NULL_ID is no longer used. What to do with it?] Doug Evans
@ 2013-12-11 20:54 ` Tom Tromey
0 siblings, 0 replies; 2+ messages in thread
From: Tom Tromey @ 2013-12-11 20:54 UTC (permalink / raw)
To: Doug Evans; +Cc: Phil Muldoon, Pedro Alves, gdb-patches
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-12-11 20:54 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-29 19:42 Python API Retention Policy [was Re: [RFC] Python's gdb.FRAME_UNWIND_NULL_ID is no longer used. What to do with it?] Doug Evans
2013-12-11 20:54 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).