This sounds exciting -- possibly you could release your patches so
they could become part of the standard distribution (possibly with
#ifdef NT around them)?
> The first step in getting Python to run in a GUI environment was to try
> and emulate the interactive input that Python gives you. This is where I
> found my problems:
> run_tty_loop ends up calling parsefile. This function ends up in a loop,
> waiting for a statement to be completed. If a multi-line command is
> types, parsefile() never returns (until complete of error detected).
> This is not suitable for a GUI program, as the program can not be
> "blocked" waiting for line based input.
> A solution for me would be to have a function similar to "run_command",
> except that it would allow the first line of a multi-line command, but
> return a result indicating that the statement is incomplete. The next
> call could be made to complete the statement. Obviously, the return
> value would have the state of the statement up until the current end of
> input. This state info would be passed back to subsequent calls.
I think this would require a complete rewrite of the parser and
tokenizer, which weren't written to be stopped and restarted.
A solution that gives a different "feel" than interactive Python in a
tty, but works well, and which is also used in GUI environments like
Smalltalk, would be to give the user essentially a "scratchpad" editor
and provide a menu or shortcut command to send the current selection
to the interpreter. With a little bit of cleverness the return key
could also make an educated guess about whether the current line is a
complete command or completes a multi-line command -- this might
improve the similarity to Python in a tty.
> My other problem is what seems to be "fprintf(stderr,...)" calls
> throughout the code. In a Windows environment, grabbing this stderr
> output so the program can use it is not trivial. My standard solution
> to this sort if thing is to provide:
> void ErrorOutput( char *format, ...)
> {
> ...
> vsprintf(buffer, format, first_arg);
> fprintf(stderr, buf);
> }
> Then, for _my_ purposes, I provide a custom "ErrorOutput" that (say)
> appends to a global bufferm that can later be viewed.
Windows continues to disappoint me. Note that most fprintfs to stderr
have already been replaced by calls to writestring(), because it must
be possible to assign a fake file (any object that has a 'write'
method) to sys.stderr to redirect Python's error messages -- those
fprintf calls that still exist should be considered debugging output
at most. I am not too fond of using vsprintf and family because they
don't exist in old UNIX systems. I also don't want to sprinkle my
code with #ifdef WINDOWS. Possibly an error function with a
non-varargs function would cater for most situations?
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>