From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25959 invoked by alias); 25 Apr 2012 08:13:47 -0000 Received: (qmail 25788 invoked by uid 22791); 25 Apr 2012 08:13:43 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Apr 2012 08:13:29 +0000 Received: by qcsd16 with SMTP id d16so1002247qcs.0 for ; Wed, 25 Apr 2012 01:13:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=WbDlVlsbHmOVJC2FFHIk64YMJcRuhcAZb4ze2trkWEU=; b=mHNHzUvogzsKfw7MtpA7+MhPAzEp3n4GZPS5ROSCfGfmGKbC89XhFTRUj3ah9CW8mg j0mW4W1dWBVTkZOCPYyaWeL/2hzAcrTxCJ4LTJjBc7W/Gta6Ke8Jlfe+eOH9ExIgaZ0n UzHSi/s8yn+G0t5OJlzm6P34ScCyclNg0UVG4pLWo2SjhgPV77n4QUYU5jMwilqpYiID I0FDwLsXTdpab3pwAMPcmai9VAw+ORbF0Xi0BHXqE3K65+AlZz2gpuewO0Gi8Kh+F79q PMvah2ztZBRsHa61aaNvktY56cfW9p8CX85bnNJ6eFJGFkf+gBm5nlQ6uqtrGyXCixAO aUiw== Received: by 10.229.135.141 with SMTP id n13mr310708qct.25.1335341608504; Wed, 25 Apr 2012 01:13:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.141 with SMTP id n13mr310699qct.25.1335341608315; Wed, 25 Apr 2012 01:13:28 -0700 (PDT) Received: by 10.224.215.132 with HTTP; Wed, 25 Apr 2012 01:13:28 -0700 (PDT) In-Reply-To: <87ehrcco7v.fsf@fleche.redhat.com> 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> <87ehrcco7v.fsf@fleche.redhat.com> Date: Wed, 25 Apr 2012 08:19:00 -0000 Message-ID: Subject: Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included) From: Siva Chandra To: Tom Tromey Cc: Eli Zaretskii , Phil Muldoon , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnxweYWodAlkus7jfsSUrhOJTk6LhKmWugYEvvnQPDdDEHFg+5CUqcCHvHzN9JJLATQI8MqIWdj3Q/ga8jpK24Yt9xEMTMKIbfp5UgvgfSp/QnpxlvYqbRvW6HdkY/thHvLTzJ1MSkDAmFkZqsAU6/nld/eUQ== X-IsSubscribed: yes 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/msg00849.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. =A0Saying 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. Tom> I think the difficulty here is that saying nothing may also lull Python Tom> users into a false sense of security that we will not change things in Tom> this area. Tom> But, we'd still like the freedom to change things. =A0For example, we'= ve Tom> talked off and on about implementing "hierarchical" symbol tables, whe= re Tom> the symbols in a namespace (e.g.) are kept in the namespace symbol, not Tom> globally. Tom> If we made this sort of change, then iterating over the block would Tom> return different results. Tom> Maybe there is some way to rewrite the original text to give us some Tom> leeway. Does this look good: http://sourceware.org/ml/gdb-patches/2012-04/msg00847.= html It adds a general note about symbols in a block under 'Blocks In Python'. Thanks, Siva Chandra