[Python-ideas] Remove tty module

[Andrew Barnert]

On Aug 2, 2013, at 6:15, random832 at fastmail.us wrote:

> On Fri, Aug 2, 2013, at 2:03, Andrew Barnert wrote:
>> I went with the idea of only allowing consoleio functions inside an
>> enabling() context (or explicit enable() and disable() calls) instead of
>> switching on the fly. It makes khbit easier to implement and to use, and
>> it's generally simpler, cleaner, and more efficient, and I don't think
>> anyone will complain too much.
>> 
>> Anyway, if something like were added to the stdlib, it definitely
>> wouldn't allow us to deprecate tty or termios (especially since it uses
>> them… but even if it didn't, sometimes you need more flexibility), but it
>> would allow us to add a note at the top saying "If you're using looking
>> for simple, more-portable raw I/O, see the consoleio module."
> 
> I don't think deprecating termios was ever on the table. As for
> "sometimes you need more flexibility" - as I understood it, the problem
> is that tty occupies an intermediate stage of flexibility/complexity -
> it's unlikely that you need more than consoleio without needing termios.
> (or curses, if we add screen manipulation functions)

What about cbreak mode? It's a useful thing, there's no obvious way to fit it into the conio-style paradigm, and tty wraps it up for you.

The fact that you also need termios to stash and restore the terminal settings if you want to leave cbreak mode is a problem, but that might be best handled by adding a simple wrapper for that to tty, rather than trying to add cbreak mode to consoleio.

> I really do think this should also include a clrscr/gotoxy

As I said in my last email, that implies that we need either curses or a whole lot of code rather than just termios, and more importantly that nobody can use consoleio without going into a curses full-screen mode.

We could of course have two different modes that you can enable (just raw I/O vs. curses full screen), where the functionality that's common to both has the same names both ways, which you suggest later. But I'm wary about that, because getwch, kbhit, etc. based on curses will have many subtle differences from implementations based on select and raw mode.

> (and
> attribute functions - you mentioned setbg/setfg in DOS versions, but
> conio.sourceforge.net has textcolor/textbackground/textattr instead)

This is one of the traditional problems with conio--there were various different libraries for it, some following Microsoft's names, some Borland's. (Borland also had some extended functionality that got compiled and linked into your code if you used it whose license was never totally clear, and there were various clones of that functionality. I think the library you're looking at on PyPI is a wrapper around such code.)

At any rate, formatted output is a pretty different problem from raw I/O, and I think it should be solved separately--especially since there are already so many mature solutions out there (some of them including functionality we'd never dream of adding to the stdlib, like dithering jpg files to ASCII art). And as I said in the other email, there are good use cases for wanting one without the other. The fact that they both happened to be implemented with related APIs in DOS, and that there are emulators for those APIs for Windows, doesn't mean they have to go together in the stdlib.