From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14409 invoked by alias); 10 Feb 2009 01:37:55 -0000 Received: (qmail 14401 invoked by uid 22791); 10 Feb 2009 01:37:54 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Feb 2009 01:37:46 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n1A1bfLe020737; Mon, 9 Feb 2009 20:37:41 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n1A1beFh013847; Mon, 9 Feb 2009 20:37:40 -0500 Received: from opsy.redhat.com (vpn-12-231.rdu.redhat.com [10.11.12.231]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n1A1ben9000361; Mon, 9 Feb 2009 20:37:40 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 4A7978880F4; Mon, 9 Feb 2009 18:37:38 -0700 (MST) To: Eli Zaretskii Cc: Doug Evans , gdb-patches@sourceware.org Subject: Re: RFC: add ability to "source" Python code References: From: Tom Tromey Reply-To: Tom Tromey Date: Tue, 10 Feb 2009 01:37:00 -0000 In-Reply-To: (Eli Zaretskii's message of "Mon\, 09 Feb 2009 06\:08\:21 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-02/txt/msg00215.txt.bz2 >>>>> "Eli" == Eli Zaretskii writes: Eli> To clarify, I think "source" without Python compiled should behave Eli> exactly as it did before this patch: treat foo.py as any other file Eli> name and treat -p as it does today (i.e. source "-p foo.gdb" if it Eli> exists). Eli> Yes, this is called "backward compatibility". It just could be that Eli> one reason why someone configures GDB without Python is that they Eli> don't want this incompatible change. I find this difficult to swallow. This argument is that someone out there finds the need to source a file named "-p something" so compelling that he disables Python support rather than simply writing "source ./-p something". My view, instead, is that users generally do not use files with weird names, or put gdb scripts into files with extensions clearly used by other languages, or do other odd things like that. And, if they do, they will not mind renaming these files after a major release of GDB. Major releases are when we can break some things in order to make GDB better overall. I do not think we should be constrained by scenarios like this one, scenarios which, IMNSHO, have never once happened in real life. The reason I made the "source" command work the way I did is that it is a familiar pattern to Unix users: you provide an option to get an effect, and if the tool cannot provide that effect, you get an error. Tom