[Python-ideas] Default value for input

[Ron Adam]

On 04/04/2014 02:01 AM, Andrew Barnert wrote:
> 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.

I think you are thinking of a more complete solution than I am.


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

Which ever way would work best, but still result in a single API for all 
platforms.  If number #1 can work, that would be fine, but I suspect there 
would be a lot of edge cases to resolve to get the wrappers to act alike, 
if it's even possible to do.

I was thinking of just having the basics of #2 in place.  Then wait a bit 
to see how it's used and not try to duplicate readline.  Not everything 
needs the full features of readline.

And it may be possible to switch to simple (option #2) input mode 
temporarily and then back to readline or it equivalent mode.  (?)

In any case.  If you still think it's a bad idea,  I'm fine with that.


>>> >>  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…)


Well.. don't do that.  ;-)

Cheers,
    Ron