From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31452 invoked by alias); 26 Mar 2008 22:36:30 -0000 Received: (qmail 31441 invoked by uid 22791); 26 Mar 2008 22:36:29 -0000 X-Spam-Check-By: sourceware.org Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.188) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Mar 2008 22:36:11 +0000 Received: by fk-out-0910.google.com with SMTP id 26so5187249fkx.8 for ; Wed, 26 Mar 2008 15:36:09 -0700 (PDT) Received: by 10.82.154.5 with SMTP id b5mr16898bue.10.1206570968784; Wed, 26 Mar 2008 15:36:08 -0700 (PDT) Received: by 10.82.162.12 with HTTP; Wed, 26 Mar 2008 15:36:08 -0700 (PDT) Message-ID: <8f2776cb0803261536r568dcbecpa8b6c6a1a6ffb622@mail.gmail.com> Date: Wed, 26 Mar 2008 22:45:00 -0000 From: "Jim Blandy" To: "Paul Koning" Subject: Re: repo to work on python scripting support Cc: tromey@redhat.com, bauerman@br.ibm.com, gdb@sourceware.org In-Reply-To: <18410.23162.503583.519896@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1205538908.6643.138.camel@localhost.localdomain> <1206369478.29533.15.camel@localhost.localdomain> <20080325114520.GA21688@caradoc.them.org> <8f2776cb0803251118o316d261erb340d67bb0580967@mail.gmail.com> <18409.18988.613477.542099@pkoning-laptop.equallogic.com> <18409.21257.48822.645806@pkoning-laptop.equallogic.com> <8f2776cb0803251441m169bfcddkb12bc8873bd4cf8f@mail.gmail.com> <18410.23162.503583.519896@gargle.gargle.HOWL> X-Google-Sender-Auth: 4b75be450b774c6a X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00258.txt.bz2 On Wed, Mar 26, 2008 at 7:15 AM, Paul Koning wrote: > It seems to me that there's an attempt here to treat Python as if it > were Elisp. But it isn't, and it isn't similar. You're right, Python and Emacs Lisp are not the same, and we shouldn't thoughtlessly adapt ideas from Emacs Lisp to GDB Python. However, Emacs does have a similar situation to the one we have here, in that Emacs commands are simultaneously: - ordinary Emacs Lisp functions callable from Lisp, and - interactive commands that can be bound to keys or invoked by name, and when this happens need to prompt or otherwise gather their arguments appropriately. This is directly analogous to what we're doing with GDB. We want user commands and functions to be simultaneously: - Python functions (or at least objects) that can be used in the ordinary fashion in Python code, and - either commands that can be typed at the (gdb) prompt, or functions that can be used in GDB expressions using the $(FUNC ARGS) syntax. So I think it's a sound analogy that rests on the novel uses to which we're putting functions, not on anything specific to Emacs Lisp. > In Python, the caller picks the type of the arguments (implicitly, by > picking the variables and expressions in the call). The called > function then either examines what it received and converts as needed, > or assumes that what it got was what it wanted and uses exceptions to > convert as needed, etc. I'm proposing we continue to use Python in exactly this way. > If you add decorations of some sort, or magical methods in classes, to > do Elisp-style argument mapping, a Python programmer is going to look > at that and say "what language is this?" Have you written code in Emacs Lisp? It sounds like you've gotten the impression that what's going on is much more magic and involved than it really is. It's possible to write Emacs Lisp functions that work like the Python code you posted that checks arguments against None and prompts for them if needed. They would work fine, and interactive users wouldn't be able to distinguish them from ordinary Emacs commands. But Emacs Lisp coders don't write their functions this way: - They would lose error checking when calling their functions from Lisp: if they forget an argument to the function, the function will prompt interactively instead of raising an error. - They would lose the ability to use optional arguments in the way one usually does --- when there's an obvious or useful default, or for backwards compatibility. Instead of using default values, the function would have to prompt for their values interactively. - Interactive specs are often terser, and because they're an idiom they're a little easier to read.