-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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 and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove "slave" variable #30058
Remove "slave" variable #30058
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is standard terminology for PTYs (https://en.wikipedia.org/wiki/Pseudoterminal).
Seems to be indeed, the point is do we need to use that same terminology here and doesn't "worker" convey the same idea? |
Any other word than the established terminology is likely to be confusing since it will bring erroneous connotations. |
No, not really, not if you still want it to be meaningful rather than just getting rid of the word "slave". The slave here means it's attached to the master, whether it is doing any work or not isn't the point. And FWIW, it's the code that uses the "slave" that's the worker, not the slave itself. |
While "slave" may be the standard term for this, should it be? I know it's "just a word" but consider the following thought experiment. Imagine you are a member of a population which has been enslaved in recent history and for whom this is still a very charged word. You're just going about your day, reading some code and then—BAM—you encounter this word in the code. Suddenly you're taken straight out of the realm of code and instead of working, you're thinking about all sorts of truly disturbing, horrific history that may be only a few generations in your past. Should people have to experience that while reading code? For very similar reasons we wouldn't use the word "holocaust" or "rape" in code, why is "slave" ok? In another 100 years when slavery is (hopefully) long in everyone's past, maybe we can use this word without risking bringing back painful, recent history to anyone, but we are not there yet. Let's try to find another way to write this. |
As I said, if we for external reasons need to rename this variable from the universally established name, I would suggest a name like Names like |
Neither of those strike me as a good faith response—they both seem like things you're saying just because you are against this change. Replacing "slave" with "xxxxx" to "force people to look it up" is not a reasonable suggestion that you'd make for any other change of variable name or terminology. The word "execute" has multiple different common meanings, including "carry out or put into effect". In fact, this is the more general meaning: when someone is executed, it is so called because their sentence—death—is "carried out" or "put into effect". So the meaning with which it is used in a programming context is, in fact, the primary one. Fortunately, not that many people would have that association and be disturbed by the word "execute". If that were not the case and there was a risk that a significant portion of the population might find "execute" disturbing or distracting, I would also want to find a different word for that. |
A compromise might be something like That way, we also prevent well-meaning but misguided future complaints or PRs to change the variable name. |
Surely, the etymology of a word cannot be of importance in cases like this. Your thought process regarding this was: "imagine that someone was in this situation and they have a bad reaction to reading this word". I tried to do the same thing. How can you say their reaction is less appropriate than the other?
The reason I wouldn't suggest that is that for other changes to variables or terminology, we do it to make things easier for the reader to understand. We do this by using words that are more accurate for the field. Here, due to external reasons, we are trying actively to make things harder to understand by not choosing the word that is universally used, so it requires special consideration. Not saying anything at all ( |
Sounds good to me. |
It's not, my point was not about etymology, it was about meaning and generality:
I can't and I don't. If someone has a really negative reaction to the word "execute", I can't argue with that. However, we have to make reasonable judgments about things and that seems like it would not be a reaction for a sizable portion of people. My argument is that we cannot say the same about "slave". |
Not sure I find |
Clearly, it doesn't have one meaning which is why we are talking about this at all. Just looking in the dictionary we have:
|
That definition is subsidiary to (literally a bullet point under) "a person who is the legal property of another and is forced to obey them." The device meaning is an analogy of that one. But arguing about linguistic minutiae is really beside the point here, isn't it? |
|
That was indeed my point that etymology shouldn't matter but that's exactly what we are discussing now. What is derived from what etc. Anyway, for this PR perhaps make the |
this might be worth having more people expressing their opinion on this topic. |
I disagree (preference: someone acts as BDFL, makes a decision and ends this discussion). But since I expressed my opinion already, I might as well explain it. The variable naming should reduce friction for developers reading the code. I see three types of friction here:
Number (1) is a real issue, as evidenced by Kristoffer's reaction. Number (3) is a real issue as well, as evidenced by the existence of this PR and Stefan's reaction. I don't have an opinion on how problematic issue (2) is. If anyone here is personally affected by (2), please come forward and help us fix this for you. Now we need to reconcile (1), (2) and (3). An obvious way of moving away from the unqualified use of "master" / "slave" is to add qualifications. We are not talking about "slaves" anymore, we are talking about a PTY acting in the unfortunately named function of "slave" in a protocol from the 70s (I guess?). It now is obvious that "slave" is not an inconsiderate choice of us, but that it instead refers to a technical term that witnesses bad taste in naming decades ago. This is a strict improvement over the old name, especially in view of (3); and the variable is even more descriptive now. I hope this resolves (3) and preserves (1). Unless personally affected people come forward, I am very unconvinced that (2) will be an issue after this change. If the name absolutely must be changed from |
Happy to oblige. Let's change the names to |
AFAIU, that is not how the julia project is governed. Putting a triage label. Regarding " |
Other projects have been through this discussion before, so fortunately we don't need to repeat all of it. I found for example https://bugs.python.org/issue34605 where the resolution was to change these terms in every case except PTYs. But, I would like to point out that the word does not occur in our APIs or documentation, and I am pretty sure we have never used the word anywhere we had a choice. In this case though I don't have a strong opinion, since these are variable names in test code and a script, so they have low visibility and the impact is very small either way. |
outdated—terms are now pty_{master,slave}
Changing the terms to |
ok, so this version should be good, I'm not modifying anything if the consensus is maintained on pty_{slave,master}. |
* replace master, slave -> pty_master pty_slave
We should rename |
After some discussion using |
We decided to get rid of the master/slave terminology in Julia in #30058. However, we decided to keep it for PTYs, where the terminology is imposed upon us by POSIX (and thus changing it would be confusing for people who might need to read up on the POSIX definitions of these concepts). It was recently suggested to revisit this, by renaming to ptm and pts instead, which also fit well (as the devies that the fds refer to are `/dev/ptmx` and `/dev/pts` respectively), are googleable (`pty pts` will yield the correct man page) and will probably need to remain even if POSIX adjusts their terminology, since they're part of the ABI (presumably they'll be backronymed to whatever terminology ends up winning). This patch does this rename.
We decided to get rid of the master/slave terminology in Julia in #30058. However, we decided to keep it for PTYs, where the terminology is imposed upon us by POSIX (and thus changing it would be confusing for people who might need to read up on the POSIX definitions of these concepts). It was recently suggested to revisit this, by renaming to ptm and pts instead, which also fit well (as the devies that the fds refer to are `/dev/ptmx` and `/dev/pts` respectively), are googleable (`pty pts` will yield the correct man page) and will probably need to remain even if POSIX adjusts their terminology, since they're part of the ABI (presumably they'll be backronymed to whatever terminology ends up winning). This patch does this rename.
We decided to get rid of the master/slave terminology in Julia in JuliaLang#30058. However, we decided to keep it for PTYs, where the terminology is imposed upon us by POSIX (and thus changing it would be confusing for people who might need to read up on the POSIX definitions of these concepts). It was recently suggested to revisit this, by renaming to ptm and pts instead, which also fit well (as the devies that the fds refer to are `/dev/ptmx` and `/dev/pts` respectively), are googleable (`pty pts` will yield the correct man page) and will probably need to remain even if POSIX adjusts their terminology, since they're part of the ABI (presumably they'll be backronymed to whatever terminology ends up winning). This patch does this rename.
The term is considered obsolete and all occurrences were replaced by "worker"