From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21993 invoked by alias); 25 Apr 2012 06:36:40 -0000 Received: (qmail 21915 invoked by uid 22791); 25 Apr 2012 06:36:38 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Apr 2012 06:36:26 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3P6aLte017938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Apr 2012 02:36:21 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3P6aKIf006710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 Apr 2012 02:36:20 -0400 From: Tom Tromey To: Eli Zaretskii Cc: Phil Muldoon , sivachandra@google.com, dje@google.com, ratmice@gmail.com, gdb-patches@sourceware.org Subject: Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included) References: <831unms3jy.fsf@gnu.org> <4F8F187D.3050402@redhat.com> <878vhsojgd.fsf@fleche.redhat.com> <87sjfyi5rj.fsf@fleche.redhat.com> <87lilmh9jf.fsf@fleche.redhat.com> <83y5pmft8k.fsf@gnu.org> <4F95630D.1000202@redhat.com> <83vckqfpzb.fsf@gnu.org> Date: Wed, 25 Apr 2012 07:11:00 -0000 In-Reply-To: <83vckqfpzb.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 23 Apr 2012 18:05:28 +0300") Message-ID: <87ehrcco7v.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00846.txt.bz2 Phil> I am just not sure we should have compatibility warnings that the Phil> content/structure of these blocks may change in some undefined way, Phil> at some future time. Eli> With that I agree. Saying such things in a manual is never a good Eli> idea, unless we also describe in detail what exactly can go wrong, how Eli> to detect that, and how to work around. I think the difficulty here is that saying nothing may also lull Python users into a false sense of security that we will not change things in this area. But, we'd still like the freedom to change things. For example, we've talked off and on about implementing "hierarchical" symbol tables, where the symbols in a namespace (e.g.) are kept in the namespace symbol, not globally. If we made this sort of change, then iterating over the block would return different results. Maybe there is some way to rewrite the original text to give us some leeway. Tom