[Python-3000] Pre-PEP: Simple input built-in in Python 3000

[Guido van Rossum]

On 12/23/06, Calvin Spealman <ironfroggy at gmail.com> wrote:
> On 12/23/06, Guido van Rossum <guido at python.org> wrote:
> > On 12/23/06, Calvin Spealman <ironfroggy at gmail.com> wrote:
> > > I was reading the thread and wanted to make a comment about the "input
> > > from a GUI". It should be noted that whatever the names of these
> > > functions, or their allowed parameters, etc., the idea of them being
> > > more than console IO should be allowed for. The builtins should be
> > > easily redefinable when you run a script (at least optionally, in the
> > > future) to use a simply prompt GUI and dialogs, etc. Even if the
> > > script was written without such in mind.
> > >
> > > Is this too much to consider?
> >
> > It is already easy enough to replace any built-in in a specific
> > environment. I don't think we need to make this part of the spec for
> > input(). For example, it should be trivial to write a little driver
> > program that takes a script file and further arguments (for the
> > script) and runs the script in an environment where stdout/stderr go
> > to a Tkinter text window (or Gtk, or whatever) and input() pops up
> > some kind of dialog, for example. IDLE does something like this; its
> > input() reads from the console window.
>
> I was meaning to say that the functions be defined such, just that the
> idea is kept in mind throughout the discussions about them and thus
> nothing is done to make such usages less nice. For example, this would
> be additional reason to avoid newlines in the input.

Oh, don't worry. I'm not about to let input() return a string ending
in a newline; that would just add an unnecessary hurdle to one's first
program. I suppose that when input() is implemented as a dialog box,
there could be a Cancel button that causes it to raise EOFError.

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