Example:
1) Do `C-c !' to start up a Python process. When I do this, I see a new
"*Python*" buffer that looks like:
Python 0.9.4 alpha (>= Dec 24 1991).
Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
>>>
2) In a .py file, set the region around the following three lines:
a = 9
b = 12
print a
3) Do `C-c |'. When I do this, I see the Python process buffer change
to:
Python 0.9.4 alpha (>= Dec 24 1991).
Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
>>> >>>
I.e., there's just one additional prompt, and typing stuff in
confirms that "a = 9" is the only line Python actually saw.
In other words, Python only sees (or acts on) the stuff up thru the
first newline. This is *not* due to some buffer overflowing in our
system: I can send a Python statement containing many thousands of
characters, and it works fine so long as it's the only statement. It's
not really a problem with multiple statements, either -- slamming
multiple statements into a line works fine so long as they're separated
by semicolons. But use newlines instead of semicolons, & only the first
statement "works".
I don't think our Emacs is busted, either. E.g., after
(make-shell "Cat" "cat")
I can process-send-string strings with multiple newlines to the "Cat"
process and they all get echo'ed. Ditto to shells, etc.
In fact, everything I've tried sez that the problem is unique to running
an interactive Python process. Guido, does this make any sense to you?
E.g., in interactive mode, does Python perhaps just ignore stuff after
the first newline (between printing prompts, that is ...).
One thing that does work: breaking the input into lines, & sending them
to the Python process one at a time, waiting for a prompt after each.
That's easy enough to do in Elisp, but shudder <grin>.
An entirely different (i.e., not directly to do with py-mode) problem:
def fac(n):
if n <= 2: return n
return n * fac(n-1)
fac(6)
That works fine if run as a Python script. However, if typed in to an
interactive Python, the "fac(6)" triggers
fac(6)
^
Unhandled exception: SyntaxError: invalid syntax
apparently because in interactive mode Python wants to see an empty line
terminate the def. A consequence is that py-execute-region won't always
work as expected (when a Python process is active) even if the newline
mystery is cleared up. This one clearly appears to be a flaw (or
feature <ahem>) of Python itself. Agreed?
at-least-i'm-learning-a-lot-about-elisp<grin>-ly y'rs - tim
Tim Peters Kendall Square Research Corp
tim@ksr.com, ksr!tim@uunet.uu.net