Re: repo to work on python scripting support

["Jim Blandy" <jimb at red-bean dot com>]

On Wed, Mar 26, 2008 at 7:15 AM, Paul Koning <Paul_Koning@dell.com> 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.