[Python-Dev] Incorrect documentation of the raw_input built-in function

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