Re: repo to work on python scripting support

[Paul Koning <Paul_Koning at dell dot com>]

>>>>> "Jim" == Jim Blandy <jimb@red-bean.com> writes:

 Jim> On Tue, Mar 25, 2008 at 12:31 PM, Paul Koning
 Jim> <Paul_Koning@dell.com> wrote:
 >> The notion of asking for a particular type is a bit foreign to
 >> Python; arguments have no fixed type.

 Jim> It's not really about type.  For example, Emacs has about a
 Jim> dozen interactive spec code letters that compute string
 Jim> arguments for the function.  Some are filenames, some are buffer
 Jim> names, some are bits of text...  It's about how to prompt for
 Jim> the arguments.  Or, in the case of $() functions in GDB, how to
 Jim> parse the arguments.

 >> Another possibility is to pass strings but then have standard
 >> conversion routines (things callable by Python and supplied by
 >> gdb).  For example parse_and_eval_address.  And the target
 >> functions.  And so on.
 >> 
 >> def walklist (head): addr = parse_and_eval_address (head) while
 >> addr: print "list item at", addr addr = target_read_memory (addr,
 >> 4)

 Jim> Using "None" this way means that the function's arguments are
 Jim> (say) "address, or None if I should prompt interactively."

 Jim> The nice thing about interactive specs is that the function
 Jim> itself has a single contract to follow: each of its arguments
 Jim> always means the same thing, whether the function is invoked
 Jim> from code or interactively by the user.

 Jim> You may also get interactive prompting by accident, if you pass
 Jim> the wrong arguments to the function.

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.

The goal of supporting Python scripting should be to provide an
environment that is familiar to Python programmers.  That means
passing arguments in the way Python normally does.  That is not the
way Elisp does it.

If you're going to merge Elisp and Python, you're creating a new
programming language.  There may be good reasons for inventing a new
scripting language, but if that's the plan, it shouldn't be descriped
as supporting Python for scripting.

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.

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?"

   paul