@gpshead as a merger of the previous PR in the series.

@gpshead Sorry about the multiple edits.

Goal

To add functionality that lets one easily manipulate a terminal attribute list like the one returned bytermios.tcgetattr().
Functionality of thecfget*(),cfset*(), andcfmake*() C functions in the list below must be added. Additionally, our new functions should also be able to set terminal attribute lists to the terminal combination modes listed in the next section.

The following is a list of items of the following format:

*nix tty or pty-related C function:OS/standard:Python function that covers functionality (if any).

A check mark indicates availability in Python.

• isatty():POSIX:os.isatty()
• ttyname():POSIX:os.ttyname()
• tcgetattr():POSIX:termios.tcgetattr()
• tcsetattr():POSIX:termios.tcsetattr()
• tcsendbreak():POSIX:termios.tcsendbreak()
• tcdrain():POSIX:termios.tcdrain()
• tcflush():POSIX:termios.tcflush()
• tcflow():POSIX:termios.tcflow()
• tcgetwinsize():upcoming POSIX:termios.tcgetwinsize()
• tcsetwinsize():upcoming POSIX:termios.tcsetwinsize()
• openpty():Linux,*BSD,Solaris:os.openpty() andpty.openpty()
• forkpty():Linux,*BSD,Solaris:os.forkpty() andpty.fork()
• login_tty():Linux,*BSD,Solaris:os.login_tty()
• cfgetispeed():POSIX
• cfgetospeed():POSIX
• cfsetispeed():POSIX
• cfsetospeed():POSIX
• cfsetspeed():Linux,*BSD
• cfmakeraw():Linux,*BSD:None sincetty.setraw() appliestermios.tcsetattr()
• cfmakesane():FreeBSD
• ptsname:POSIX

Note: Python also includesos.get_terminal_size() which is not *nix-specific.

Edit: Various pty-related functions such asposix_openpt(),getpt(),getpty(),grantpt(),unlockpt() are all covered byos.openpty(). Only having a Python version ofptsname() would be interesting sinceos.forkpty() does not return the path to the slave end of the pty.

Terminal combination modes

From POSIX manpage forstty:

• oddp
• parity, evenp, or oddp
• raw
• -raw or cooked
• nl
• -nl
• ek
• sane

and one fromhttps://en.wikipedia.org/wiki/Terminal_mode:

• cbreak or rare

Note: Python already includes convenience functionstty.setraw() andtty.setcbreak() but they calltermios.tcsetattr() for you. For example, you might want to set your terminal attribute list to raw except that you might want to keep theECHO flag enabled before applyingtermios.tcsetattr().

Relevant manpages

• POSIX:https://pubs.opengroup.org/onlinepubs/9699919799/
• Linux:https://man7.org/linux/man-pages/man3/termios.3.html
• FreeBSD:https://man.freebsd.org/cgi/man.cgi?query=cfmakeraw&apropos=0&sektion=3&manpath=FreeBSD+9-current&format=html
• NetBSD:https://man.netbsd.org/cfmakeraw.3
• OpenBSD:https://man.openbsd.org/cfmakeraw

@gpshead Thank you for merging this.However, I have been working on an idea which makes this obsolete. That is why I had converted this PR into a draft (in hindsight, I should have requested you to mark it as DO-NOT-MERGE). Let me explain below.

While working on this PR, I was wondering what the point of thetty module was. On the one hand it looks like it is the place for convenience functions that are not modeled after standard POSIX (or maybe even BSD) functions. On the other hand it imports * from termios, and I have seen people usetty andtermios in the same file in an almost interchangeable manner, which seems very "indisciplined" to me.

Upon digging through the source I realized that Steen Lumholt had originally written his 2 functionstty.setraw() andtty.setcbreak() for convenient use in only 2-3 places in Python source (if I recall correctly): a quickgrep showed thattty.setraw() is used in thepty module andtty.setcbreak() was used in one other place.

What is more problematic is that thetty module, even after the additions that I wrote for this PR, is highly inflexible. For example, for whatever personal reason, if one wanted to modify some arbitrary attributes, then one would still have to write non-Pythonic and not-so-easily-readable code like this:

import termiosx = termios.tcgetattr(0)                                                                                                                                                                                            x[3] = x[3] & ~(termios.ECHO|termios.ICANON)x[2] &= termios.CSIZEx[2] |= termios.CS8x[6][termios.VMIN] = 1termios.tcsetattr(0, termios.TCSANOW, x)

The module that I have been writing is small, free of feature-creep, and uses already standard language provided bystty(1) to do the same as follows:

import sttyx = stty.stty(0)x.set(echo=False, icanon=False, csize=stty.cs8, min=1)x.apply(0)

or

import sttyx = stty.stty(0)x.echo = Falsex.icanon = Falsex.csize=stty.cs8x.min=1x.apply(0)

While I am not a core developer and am not authorized to dictate drastic changes, I am going to request that you consider marking thetty module for deprecation and consider my new module instead. At the very least, maybe just take a look at my source: you can decide whether to keep it or not.

I just defended my PhD dissertation and will be away for 2 weeks for several conferences; when I return after June 10, I will make some final changes to thestty module and upload it here for you to view. Please let me know if this sounds acceptable and if there is any specific procedure to get a new module authorized.

Nice writeup, thanks! I'm not concerned about having merged and added this. They are trivial low level API additions.

We don't have thetty ortermios orpty modules on our radar for stdlib deprecation and removal anytime soon (seehttps://peps.python.org/pep-0594/ for our current list), but it is not unreasonable to think some of that could be consideredsomeday. They're basically un-owned areas of the stdlib with no expert behind them that serve as very low level wrappers over the C APIs (much like what we do in theos module) so they don't provide a "good" interface for anyone to code to. From my POV, you count as the expert at this point. :)

If you do create a nice Pythonic interfacestty API, please put it up on PyPI for starters. We could link to that from the stdlib documentation as a suggestion for a nicer interface.

We want to be very conservative on adding major new interfaces to the standard library, and the same with removing old things if they are not a burden. Adding stty would be a valid thing to ask for in the future, but having something up on PyPI to see actual use by others is what we always recommend for starters.

Completely makes sense! Thank you. I will let you know upon publishing it on PyPI within the next month or so.