From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 8C0A3395201B for ; Thu, 29 Apr 2021 10:08:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8C0A3395201B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B0413AC38; Thu, 29 Apr 2021 10:08:50 +0000 (UTC) Subject: Re: [PATCH 7/7] gdb: startup commands to control Python extension language To: Andrew Burgess Cc: gdb-patches@sourceware.org References: <20210429094642.GF2364578@embecosm.com> From: Tom de Vries Message-ID: <70b2bb6d-f5f6-7b35-5838-8949aa422577@suse.de> Date: Thu, 29 Apr 2021 12:08:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <20210429094642.GF2364578@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 10:08:52 -0000 On 4/29/21 11:46 AM, Andrew Burgess wrote: > * Tom de Vries [2021-04-29 10:32:05 +0200]: > >> I ran into https://sourceware.org/bugzilla/show_bug.cgi?id=27788 due to >> having PYTHONDONTWRITEBYTECODE set in my environment. My guess at this >> point is that this is a test-case issue. >> >> I played around a bit with the options and did: >> ... >> $ echo $PYTHONDONTWRITEBYTECODE >> 1 >> >> $ gdb -q -batch \ >> -iex "set python ignore-environment on" \ >> -iex "show python dont-write-bytecode" >> Python's dont-write-bytecode setting is auto (currently off). >> >> $ gdb -q -batch \ >> -iex "set python ignore-environment off" \ >> -iex "show python dont-write-bytecode" >> Python's dont-write-bytecode setting is auto (currently on). >> ... >> which shows that there is an interaction between the two commands. >> AFAICT, this is not evident from either the NEWS item, or the docs, and >> I just wonder whether it's a good idea to make this explicit. > > Hi Tom, > > Thanks for looking at this feature. > > The docs for dont-write-bytecode say: > > > > By default this option is set to @samp{auto}, in this mode Python will > check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see > if it should write out byte-code or not. > > > > I guess you saw this, but it still didn't seem clear enough? > > What if this was extended to something like: > > By default this option is set to @samp{auto}, in this mode Python will > check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see > if it should write out byte-code or not. When @command{set python > ignore-environment on} has been used then Python will ignore > the environment variable and write out the byte-code files. > > I've included the patch below that would make this change. > Hi Andrew, LGTM, I just wonder if something like this is not more clear, that is, reformulate in terms of already explained option value off, rather than verbosely repeating the off behaviour. So, something like this: ... By default this option is set to @samp{auto}, in this mode Python will check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see if it should write out byte-code or not. When @command{set python ignore-environment on} has been used then auto has the same behaviour as off. ... But then again, this may be a bad idea, I'm not sure. Thanks, - Tom