bpo-34605, pty: Avoid master/slave terms by vstinner · Pull Request #9100 · python/cpython (original) (raw)
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation11 Commits3 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
- pty.spawn(): rename master_read parameter to parent_read
- Rename pty.slave_open() to pty.child_open(), but keep an
pty.slave_open alis to pty.child_open for backward compatibility - os.openpty(), os.forkpty(): rename master_fd/slave_fd
to parent_fd/child_fd - Rename internal variables:
- Rename master_fd/slave_fd to parent_fd/child_fd
- Rename slave_name to child_name
https://bugs.python.org/issue34605
suic86, afourmy, fcharlie, bumfo, francisfsjiang, atlas-comstock, 1v9, dhssingle, towerd, tiiime, and 44 more reacted with thumbs down emoji
pty.spawn(): rename master_read parameter to parent_read
Rename pty.slave_open() to pty.child_open(), but keep an pty.slave_open alis to pty.child_open for backward compatibility
os.openpty(), os.forkpty(): rename master_fd/slave_fd to parent_fd/child_fd
Rename internal variables:
- Rename master_fd/slave_fd to parent_fd/child_fd
- Rename slave_name to child_name
pty.spawn(): rename master_read parameter to parent_read
This change is backward incompatible since technically it was possible to call pty.spawn(..., master_read=..., ...). Do we need to accept master_read as a keyword parameter but emit a deprecation warning?
Rename pty.slave_open() to pty.child_open(), but keep an pty.slave_open alis to pty.child_open for backward compatibility
I dislike keep the alias. The function isn't documented. Can't we just make the function private instead?
I didn't add a NEWS entry since I'm not sure if this PR is backward incompatible or not.
(Adding my comment from bpo here since it pertains specifically to this PR)
If you look at all the current Linux man pages and documentation, they follow the master/slave terminology. Generally, Python documentation for underlying os functions like fork, stat etc are kept short because the OS documentation is the ultimate resource for them.
This change causes a deviation from the existing standard and will only serve to make things more confusing. Anyone who goes to google about a "pty leader" will find nothing. I would suggest deferring it until the actual OS documentation reflects this change as well.
IMHO it's ok for Python to use a different terminology since "master" and "slave" are not really part of the PTY functions.
In C, the parameter names don't matter. You can use any name when you call the function.
In Python, "master" and "slave" are not part of the API neither. openpty() returns a tuple, that's it. The caller has to pick two names for the pair of file descriptors.
My point is, googling for pty child descriptor is going to be a far worse search than pty slave descriptor. And sure, you can pass in whatever you want for the function argument names but the default argument names are used as implicit documentation. For example, fd is conventional for file descriptors and you can search for linux fd and get lots of relevant info.
This comment has been minimized.
Please keep motivational discussion on the bug tracker. Github is used for the technical code review.
afourmy, pitrou, kaonashi-tyc, atlas-comstock, number5, oldrev, jianggau, supadrupa, adamb70, rooterkyberian, and 17 more reacted with thumbs up emoji
Since this reflecting the terminology of the underlying UNIX pty mechanism it should not be changed.
atlas-comstock, cymcsg, tiiime, number5, bingtel, jianggau, dantmnf, rooterkyberian, jsnow42, enomado, and 20 more reacted with thumbs up emoji SergSlipushenko reacted with hooray emoji supadrupa, macdewee, Jakub89, ivechan, and Ro-andrei reacted with heart emoji
