Re: [patch] Add an evaluation function hook to Python breakpoints.

[Phil Muldoon <pmuldoon at redhat dot com>]

Pedro Alves <pedro@codesourcery.com> writes:

> Can you factor out the PyObject manipulations and the actual evaluation
> of the condition to pythong/py-breakpoint.c?  Say, to a
> new "py_breakpoint_evaluate (struct breakpoint_object *, ...)" function.
> The driving idea being to get rid of the need to now include
> python-internal.h.

Sure I've no problem with that. I think we would still have to include
python.h (but not python-internal.h) inside a HAVE_PYTHON conditional, as
the function would be exposed from py_breakpoint.c via python.h.  Is
that ok? Or maybe I misread your intentions.

> My first reaction was 'why not call the field "condition"?  "evaluate"
> sounds like it's about watchpoint evaluation or some such to me.  Point
> being, that there are several different things that are evaluated, and
> so it kind of sounds ambiguous.  OTOH, there's chance of confusion with
> the condition expression set with the "condition" command.  Is that one
> exposed to python?  It may be worth it to think a bit about that, so to
> make sure the docs and api doesn't end up confusing when you end up
> exposing that condition too.  I'm okay with whatever you guys come up
> with, just pointing it out.

We do expose the "condition" API currently, but it is a read-only
attribute that exposes any conditions set via the CLI.  I've no opinion
what we should call the Python conditional evaluation.  I picked
"evaluate" for no particular reasons (and we are evaluating code).  I'm
open to ideas; changing the name is pretty trivial.

Cheers,

Phil