[Python-Dev] Incorrect documentation of the raw_input built-in function (original) (raw)

Guido van Rossum guido at python.org
Mon Jan 28 20:30:31 CET 2008

On Jan 28, 2008 11:17 AM, Steve Holden <steve at holdenweb.com> wrote:

> That's a dangerous generalization from just one example. I'd prefer it > if you could unearth some POSIX or Linux base document saying this. > While I couldn't locate such a document, it makes sense when you consider that if such a process is part of a pipeline you really don't want the prompts being handled as input by the downstream processes.

That's why mv and similar utilities prompt on standard error. I'd be very surprised if you can find a UNIX or Linux shell, for example, that prompts on standard output.

Ah, indeed. It looks like Python's prompt indeed gets written to stderr, at least when stdout is redirected to a file. Oddly, when stderr is redirected to a file, the prompt gets written to stdout. This seems backwards then (and not what the shells do -- when stderr isn't interactive, they don't write a prompt at all).

But fixing it is delicate -- e.g. getpass very carefully makes sure to write to stdout, not stderr (and to avoid raw_input() and hence GNU readline). And cmd.py (used by pdb.py) also assumes the prompt should go to stdout when it is not using raw_input.

I'm beginning to think that, despite the example of the shells, we'd be better off if Python always prompted to stdout (or not at all if that's not a tty).

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list