Remove "slave" variable

[matbesancon]

The term is considered obsolete and all occurrences were replaced by "worker"

[KristofferC]

This is standard terminology for PTYs (https://en.wikipedia.org/wiki/Pseudoterminal).

[matbesancon]

Seems to be indeed, the point is do we need to use that same terminology here and doesn't "worker" convey the same idea?

[KristofferC]

Any other word than the established terminology is likely to be confusing since it will bring erroneous connotations. worker for example is typically used to denote a spawned Julia process that one sends work to. If this has to be changed away from the established terminology for external reasons, I suggest calling it xxxx to force the person to look at the source code of with_fake_pty to figure out what it means.

[yuyichao]

doesn't "worker" convey the same idea?

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.

[StefanKarpinski]

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.

[KristofferC]

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 xxxx.

Names like execute / execution policy etc should perhaps also be crossed out since people might have had relatives that have gotten executed which must equally horrible to think about.

[StefanKarpinski]

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.

[chethega]

A compromise might be something like pty_slave and pty_master. This would more explicitly convey that we are using a pre-existing technical term that is at most tangentially related to historic slavery.

That way, we also prevent well-meaning but misguided future complaints or PRs to change the variable name.

[KristofferC]

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 put into effect.

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?

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 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 (xxxx) in those cases seems correct.

[KristofferC]

A compromise might be something like pty_slave and pty_master. This would more explicitly convey that we are using a pre-existing technical term that is at most tangentially related to historic slavery.

Sounds good to me.

[StefanKarpinski]

Surely, the etymology of a word cannot be of importance in cases like this.

It's not, my point was not about etymology, it was about meaning and generality:

1. "slave" has only one meaning, which can be disturbing or distracting to a significant population;
2. "execute" has multiple meanings, most of which are things like "execute a plan"; the fraction of people who might have a direct personal reaction to the one very specific violent meaning of the word "execute" is very, very small.

How can you say their reaction is less appropriate than the other?

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".

[matbesancon]

Not sure I find pty_slave and pty_master to be removing the problem, but if there's a consensus I can change the PR

[KristofferC]

"slave" has only one meaning, which can be disturbing or distracting to a significant population;

Clearly, it doesn't have one meaning which is why we are talking about this at all. Just looking in the dictionary we have:

a device (such as the printer of a computer) that is directly responsive to another

[StefanKarpinski]

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?

[StefanKarpinski]

pty_slave and pty_master seems like an improvement at least.

[KristofferC]

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 pty change as an incremental improvement and it can always be revisited?

[matbesancon]

this might be worth having more people expressing their opinion on this topic.
The fact that it's "standard terminology" and has always been does not mean it should not change

[chethega]

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:

1. People who expect the PTY terminology and will be confused if the PTY-slave is named "worker", even though it is not a worker thread or process.
2. People who have been affected by the institution of slavery (e.g. family history or modern slavery) feeling uneasy about the term.
3. People in the current north American culture thinking about people from point (2), or thinking about how this looks, or whether it is politically correct.

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 pty_slave, then pty_client/ pty_server is probably better than either worker or xxxxx.

[StefanKarpinski]

preference: someone acts as BDFL, makes a decision and ends this discussion

Happy to oblige. Let's change the names to pty_client and pty_server.

[KristofferC]

someone acts as BDFL, makes a decision and ends this discussion

AFAIU, that is not how the julia project is governed. Putting a triage label.

Regarding "pty_client and pty_server.", I have no idea which is the master and which is the slave. At least with master and xxxx I can figure it out by elimination.

[JeffBezanson]

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
python/cpython#9100

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}

[StefanKarpinski]

Changing the terms to pty_master and pty_slave seems in line with what Python decided here.

[matbesancon]

ok, so this version should be good, I'm not modifying anything if the consensus is maintained on pty_{slave,master}.
Since this is not modifying any behavior nor API, up to you to merge it in any next patch / 1.1

[ViralBShah]

We should rename pty_slave to pty_client. AFAICT, this will not break anything, since it is only variable names.

[Keno]

After some discussion using pts and ptm has the advantage of being googlable, as well as being the standard abbreviations and the names of the corresponding device files. Those abbreviations will also need to be kept by the POSIX standard for ABI compatibility, so whatever terminology they end up using, I imagine the abbreviations would remain. I think after the renaming, further action is probably best directed at a POSIX change request so we can get replacement terminology into the standard.