[Python-ideas] Remove tty module

[Andrew Barnert]

On Aug 2, 2013, at 5:53, random832 at fastmail.us wrote:

> On Fri, Aug 2, 2013, at 0:47, Andrew Barnert wrote:
>> The quasi-standardized core of conio is definitely not enough to write a
>> windowing library. Although some of the old DOS implementations had
>> gotoxy, setfg, and setbg functions, the Win32 implementations don't have
>> those; they just have… well, the same functions as MSVCRT's console APIs,
>> which the stdlib already wraps
> 
> Yes, but it wraps them in msvcrt; I'm proposing moving it to a
> cross-platform "conio" module.

My suggestion is to leave them there, and also leave termios and tty there, and just have consoleio use them as appropriate (in the same way tty already uses termios).
> 
> I had for some reason thought there was a gotoxy function in there.
> Regardless, that's no reason not to add one to the python library.

Sure there is. It's harder to implement, and will be less portable. Even just getting the screen width is tricky without curses.

And more importantly, a gotoxy function can only work after you've taken over the whole terminal in the same way curses does. There are a lot of things you may want to do--from getwch to setting colors--that don't require that. So, a module that didn't let you getwch unless you enter a curses-like mode would be less useful.

I think a simple consoleio module that just does nonblocking I/O is a useful thing. A separate module that does non-full-screen formatting (and there are dozens of these on PyPI) makes a nice complement. (Especially since there are good use cases for using that _without_ a terminal--e.g., creating ANSI art text files--but also of course many good use cases for doing both together.) A curses/conio wrapper for full-screen GUIs seems like an almost entirely separate thing, except for the fact that both would happen to use some of the same msvcrt calls on Windows.
> As for kbhit, you could probably implement it on unix with a call to
> select. If the tty file descriptor is ready for reading, then return
> true. The one possible wrinkle is that getwch could block if an
> incomplete multibyte character is read - something that cannot happen on
> windows.

There are other wrinkles. For example, on some posix platforms you also need to fcntl the fd into nonblocking mode.

Meanwhile, multibyte characters are not actually a problem. At an actual console, if you type one, all of the bytes become ready at the same time, so you can getwch. On a serial line, that isn't true, but it isn't true on Windows either, so you have to loop around kbhit and getch and decode manually. Keys that trigger escape sequences are likewise the same. Meanwhile, multi-keystroke sequences don't trigger kbhit until the last keystroke (and then, of course, they may trigger multiple characters), but again that's already true on Windows (although possibly more noticeable on posix, especially on OS X, where users typing option-e followed by e to get é is part of many users' unconscious muscle memory). There are also problems that are Windows specific that already affect msvcrt and fancier implementations that I haven't made any attempt to deal with, like the fact that getwch can return half a surrogate pair.

See the caveats in my readme, and the todo file, for everything I've discovered so far. And please experiment with the code and find all the problems I haven't discovered, because I'm sure there are plenty.