Re: [PATCH] Add bp_location to Python interface

[Doug Evans <dje@google.com>]

On Jan 11, 2012 1:02 AM, "Kevin Pouget" <kevin.pouget@gmail.com> wrote:
>
> I'm not sure we can really move it away from the Python/Guile API,
> because, AFAIU, this volatile aspect if purely internal. 'Normal'
> users won't ever see it.
>
> > $ i b
> > Num     Type           Disp Enb Address            What
> > 1       breakpoint     keep y    <MULTIPLE>
> >         1.1                         y     0x4562c0 in main at ../../../git/gdb/gdb/gdb.c:26 inf 2
> >         1.2                         y     0x4562c0 in main at ../../../git/gdb/gdb/gdb.c:26 inf 1
>
> will remain the same all the time, but the objects (both in Python and
> their GDB backends) in gdb.breakpoints()[0].locations() will be
> deleted and re-created at various moments (cf. previous discussions).
> So far, I couldn't really understand what's the rational behind that
> ...
>
> [I'm not sure how well you know this part of GDB, please don't
> hesitate to correct me if I'm wrong]

Yikes, missed that.
GDB internals are free to change at will, the python API is the exact opposite.
This is the kind of API addition that gives me pause.
Once it's in we're stuck.

I once wrote a doc on managing GDB features/APIs, loosely based on
what I could remember of the SystemV ABI.
The ABI elements had three stages in their life, though I don't fully
remember the details.
IMO, IWBN to have something like it for our Python API.
In particular, one could remove something, after a preset amount of
time had passed since the announcement of its pending removal.
And one could add new things without promising they'll be there forever.
That scheme is old, and my memory is sketchy.
My point is that today we don't have anything other than: "Once it's
in we're stuck." [AFAICT]

For the case at hand, IWBN to have some experience with whether this
addition works well enough that we want to keep it.
And it's not clear we can determine that without some real world use of it.