Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included)

[Phil Muldoon <pmuldoon@redhat.com>]

On 04/23/2012 02:55 PM, Eli Zaretskii wrote:
>> Date: Mon, 23 Apr 2012 14:30:02 +0100
>> From: Phil Muldoon <pmuldoon@redhat.com>
>> CC: Siva Chandra <sivachandra@google.com>, Doug Evans <dje@google.com>,
>>         Matt Rice <ratmice@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>>         gdb-patches@sourceware.org
>>
>> On 04/23/2012 02:17 PM, Tom Tromey wrote:
>>>>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:
>>>
>>> Siva> Overall, wrt this patch, what should we conclude?
>>>
>>> I think the patch is fine, and we're just discussing what exactly the
>>> manual should say.
>>
>> My view is that we should not say anything, that it will just be
>> confusing to the user.  There is no user facing concept of a "static"
>> or "global" block in GDB other than the Python API anyway.
> 
> We cannot have 2 separate APIs, one called Symtab.global_block, the
> other Symtab.static_block, without saying at least _something_ about
> what these names are about.
> 
> Also, the Python API to GDB _is_ user-level.
> 
> Apologies if I am missing the context of what you said.

I agree, and we have documentation and an API for is_static block and
is_global block APIs already.  Describing what they are now,
contextually, is fine -- no problem with that.  I am just not sure we
should have compatibility warnings that the content/structure of these
blocks may change in some undefined way, at some future time.  I think
we should document it when, and if that happens, and what, if any,
ramifications may occur. 

Arguable the above warning could apply to most of the Python API.  We
tend to just deal with it in the API when it happens.  While I
understand the well-meaning thought behind this, I am not sure it is
prudent to start this trend now.  We have an API promise to
specifically deal with these issues.  If we start warning that in the
future this feature might change, are we just creating loop-holes for
the API promise?  In fact my benchmark for exporting something to the
Python API is testing the likely-hood if it will change in the near
future.  But, to date, I find that most of GDB remains fairly
constant.

And finally, yeah that is what I mean: Python is the only user-facing
API for these attributes.  There is no conflict between something in
the CLI and something in Python.

Cheers,

Phil