Darren Dale <dd**@cornell.edu> writes:
Or just start Python with -u (unbuffered) or -i (interactive) from
within the shell. Avoids the need to change the script.
I forgot to ask, how would I do this from Emacs?
Well, let's assume that you're at the shell prompt from inside Emacs
(how you got there could depend on your Emacs setup, whether M-x shell
or some keystrokes). Then, instead of doing something like:
(shell prompt) python yourscript.py
do
(shell prompt) python -u yourscript.py
It'll run your script just as before but forceably disabling any
output buffering, which it would otherwise enable automatically when
detecting that its output did not appear to be a interactive (a TTY).
You should see anything produced by your script in the Emacs buffer as
soon as the script generates it.
To answer your other question, short answer is that saying "is a tty"
is more or less a shorthand for saying whether the output is being
displayed to a user on an interactive device.
Longer answer is that historically TTY was a teletypewriter (and still
can mean that in the context of hearing impaired phone devices today),
the idea being that a keyboard and display was used for communication.
Over time, and particular with it's use in Unix systems, it's come to
encompass the general idea of a terminal I/O device. More
specifically it is common (in the Unix world) to use the term TTY to
refer to an actual physical output device as opposed to other devices
like pipes, files, network sockets, etc...
So saying that output "appears to be a TTY" is a shorthand way of
saying that the output device appears to be a true interactive display
device rather than output being redirected to a file or other
connection. There's even a (fairly portable) C library routine called
"isatty" (is a tty) that Python uses to determine this. It's not
uncommon for an application (generally through default behavior of the
platform C library) to adjust buffering based on that status, so as to
be more efficient in the non-TTY case where interactive latency of
display is not as important as utilizing the bandwidth to the output
device most effectively.
Generally speaking, when one process opens a pipe or otherwise
controls another process, it won't appear to be a TTY to the other
process, since that process' output is going through some system
object (for example, a pipe). There are packages that in fact exist
soley to simulate TTYs (or provide PTTYs, Pseudo-TTYs) to better
simulate a user running an application, such as Expect.
Anyway, when Emacs is running the child shell, it executes that shell
as a child process for which it controls the I/O, but the connection
between Emacs and that child process is not perceived as a TTY by the
system, and thus nor by Python, so it permits more efficient buffering
to take place. Unfortunately, that more efficient buffering is not
what you want when you are working with something interatively.
Using the -u command line option tells Python to disable all output
buffering regardless of the TTY status of it's output. This is
actually even less efficient than the default TTY state (which is
typically line buffered) but it ensures you'll see everything on the
output as soon as it is generated. You can also get the same effect
by having the PYTHONUNBUFFERED environment variable set when you start
python.
-- David
