[Python-ideas] Default value for input

[Andrew Barnert]

From: Ron Adam <ron3200 at gmail.com>

Sent: Thursday, April 3, 2014 9:25 PM


> On 04/03/2014 08:41 PM, Andrew Barnert wrote:
>>  From: Ron Adam<ron3200 at gmail.com>
>>> 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.

Again, that's easy to do on both platforms, but it doesn't even begin to approach making the complete solution easy.

> 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.

There are only two things you could mean here.

1. The console class is basically a wrapper around readline or its equivalent, in which case we have no need for get_key_press or any of the other stuff you asked about.

2. The console class is just the low-level stuff that's implementable on all platforms, like reading and writing keys to the tty/console, and the higher-level function emulates readline and its platform equivalents on top of nothing but that low-level stuff.

I suspect you mean #2. In which case, again, look at how much code readline is. You're talking about duplicating all of that code, just to solve part of the problem (readline is still depending on your terminal to do a lot of the work, which you don't get in raw mode), on just one platform.

>>  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.

Impossible, of course not. Just not remotely as easy as the part you called "the hard part".

>>  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.


You're missing the point. Those work because they use the services provided by the OS, the terminal, the readline library, etc. Trying to duplicate everything that all those layers do on every platform is a lot of work, and a bad idea. It's not about whether you replace anything with that new code or use it in parallel, it's that you're trying to build that new code in the first place.

(But also, it's actually not true that they'll still work, at least not in the same problem. Try setting the tty to raw mode and then using readline and see what happens…)