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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> I'd assume scripts just check the result of Frame.unwind_stop_reason,
Pedro> and compare it to gdb.FRAME_UNWIND_NO_REASON.  That at most, they'll
Pedro> pass the result of Frame.unwind_stop_reason to
Pedro> gdb.frame_stop_reason_string.  I'd prefer to just get rid of it, but
Pedro> it may be best to keep this around for compatibility, in case a script
Pedro> does refer to gdb.FRAME_UNWIND_NULL_ID directly.

Pedro> In general, what's the policy for exposed constants like this in
Pedro> Python?

My view is that we should provide compatibility with what we document.

That is, if it is in the docs, we should not remove it.

However, there is still some leeway for change.
E.g., in this case, we don't document the value or type of the constant.
This is intentional as it gives us some freedom to change the details --
we don't generally want Python API promises to leak through to the C
code.

Pedro> +/* This is no longer used anywhere, but it's kept because it's exposed
Pedro> +   to Python.  This is how GDB used to indicate end of stack.  We've
Pedro> +   now migrated to a model where frames always have a valid ID.  */
Pedro>  SET (UNWIND_NULL_ID, "unwinder did not report frame ID")
 
For example you could remove this, and arrange to keep the Python
constant around with some suitably chosen value.  I think it just has to
be something that will never compare equal to any of the other
constants, so just None would work.

Tom