[Python-ideas] Default value for input

[Ron Adam]

On 04/03/2014 08:41 PM, Andrew Barnert wrote:
> From: Ron Adam<ron3200 at gmail.com>
>
> Sent: Tuesday, April 1, 2014 6:45 PM
>
>
>> >On 04/01/2014 07:58 AM, Steven D'Aprano wrote:
>
>>> >>  I often have the need to include a default or initial value when
>>> >>  asking the user for input. In other words, I'd like to call this:
>>> >>
>>> >>  input("What is the fish of the day? ", "trout a la
>> >creme")
>>> >>
>>> >>
>>> >>  and have the prompt be "What is the fish of the day? " and the
>> >initial
>>> >>  value in the edit buffer be "trout a la creme", fully editable
>> >with
>>> >>  whatever line editing tools are available on the user's system. There
>>> >>  are work-arounds for this lack, but they don't make a nice clean UI.
>>> >>
>>> >>  Under Linux, with readline, I can implement this relatively simply:
>
>> >One of the things I first looked for when learning python was a
>> >get_key_press function.
>> >
>> >Line input (or whole file input) is great for files, and can make reading
>> >data much faster than single character input.   But for user input, single
>> >char input can be useful.
>> >
>> >If we could read the keyboard directly with a get_key_press function,  then
>> >your request along with making curses cross platform, may be fairly easy to do.
>> >
>> >(The cross platform get_key_press function is the hard part.)
>
> Are you serious?

Sure it's only a starting point, not a end solution by it self.  I was 
including the parts you you mention below, taking into account the platform 
and console differences and returning a Unicode string.  I wasn't thinking 
of simply reading and returning the raw key codes.  Just get the input 
(including escape sequences) with out echoing it to the screen.

Probably the most straight forward way would be to import a console class, 
and initiate an instance, then use methods on it to read the input and 
write the output.  That way all the platform stuff can be abstracted away.

A higher level function that uses that class, would handle updating the 
line buffer and write those updates out to the screen.  (by calling methods 
on the instance.


> A get_key_press function is the_easy_  part. On Unix, you use termios to
> put stdin into raw mode then select or blocking-read stdin; on Windows,
> you use the msvcrt module to call the wrappers around the console I/O
> functions.

> But what do you think those functions return for, say, left arrow, or
> ctrl+end? (Even beyond non-character keys, even the characters don't
> necessarily show up as a single character, but as 1 or more bytes in the
> appropriate encoding (Unix) or 1 or more UTF-16 codes (Windows), so your
> state is less trivial than you're expecting…)

Yes, there are a lot of small details to work out.   But I don't think any 
of those are impossible to manage.


> And what are you going to do with a left-arrow key press when you get
> it? If your answer is "move the cursor left", how do you do that? On
> Windows you use console I/O functions; on Unix, you talk to termcap to
> figure out which control sequence to send and then send that; etc.
>
> And, once you've moved the cursor left, you probably want to insert
> rather than overwriting. And of course you need to be able to deal with
> input that wraps onto multiple lines; you may or may not have to do that
> wrapping yourself. And so on.
>
> And once you've solved all of that, and figured out how to keep track of
> buffers and cursor positions, then you just need to write code to
> emulate everything that each platform does for terminal line editing. To
> get an idea of how much work that is for each platform, look at the
> source to readline or libedit.

I agree although it's been a while sense I looked at the specific details.

> This is exactly why Python doesn't do any of that; it just uses readline
> (or libedit's readline-compat mode) on Unix, lets cmd.exe do its thing
> on Windows, etc. (This also makes it relatively easy for IDEs to hook
> the behavior and, e.g., make input give you a GUI window with a Tk text
> entry box.)

Those will still work.   I don't think anyone is suggesting replacing all 
of pythons console related code.


Cheers, Ron