Avoid master/slave terminology #78786
Comments
|
For diversity reasons, it would be nice to try to avoid "master" and "slave" terminology which can be associated to slavery. For more context, see: |
vstinner
added
topic-asyncio
build
|
Do you have examples of where this occurs? From https://github.com/python/cpython/search?p=1&q=master+slave&unscoped_q=master+slave I really only found the openpty function, and the man pages/argument names there already use this terminology so it wouldn't make much sense to change it there. |
|
I'm working on patches to change that. |
|
IMHO it's ok to keep the "master" term for:
To find all impacted files, I used the commend: git grep -i -E 'master|slave'|grep -v -E 'webmaster|postmaster|/blob/master/' |
|
The libregrtest change looks good but I disagree on the pty/openpty changes. 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, I would suggest deferring it until the actual OS documentation reflects this change as well. |
|
Having said that, there are situations where words are used confusingly or inappropriately, and better choices are available. (I am sometimes confused, for instance, by the use of 'client' and 'server'.) In such situations, change can be justified without reference to private complaints. |
|
I'm using "master" in memoryview because of the audio connotation ("the https://en.wikipedia.org/wiki/Audio_mastering The ManagedBufferObject is literally the source from which all views Conductors are sometimes called "Maestro", there are chess grandmasters, The term "master" has so many positive connotations that I think it is |
|
I strongly disagree with this as a general principle. "Master/slave" is a powerful, obvious metaphor which works well and is not the same as parent/child, server/client or employer/worker. In fact, in the BDSM subcultures, "master/slave" can have *positive* connotations. You want to support diversity, then why are you discriminating against that subculture? Talking about diversity: my wife is of a nationality that historically were often stolen to be slaves and indentured servants, and were discriminated against as second-class people right well into the second half the middle of the 20th century. My maternal family comes from a racial group (Slavic) which gives us the English word for slave and come from serf background. Both of us are angered by this attack on our linguistic culture. Stop trying to sanitize and infantalize language. That's far more offensive than the master/slave terminology. I'm not sorry for this impassioned plea. You want diversity, that includes people like me. |
This is too vague. Define what "diversity reasons" are and elaborate your point. Referring to some online discussions is not a way for making a serious argument. Make a point at least (i.e. define the term, add pro/contra arguments and explain why you've taken your decision). Your political standpoint is your political standpoint and it's not my business. However, making these changes without giving reasons and arguments for them is a problem. Let me ask: Are these "diversity reasons" really reasons? What I've heard seen so far regarding "diversity reasons, ..." had little to nothing to do with rational thinking or argumentation. Is it really necessary to pollute Python code base with SJW ideology/terminology? What comes next? Ad absurdum: If I find anything associated with something unpleasant to me in Python code or something which can be considered as e.g. "cultural appropriation", I'm free to change it for diversity reason? |
|
Guys, really, don't we have anything better to do with your time than this silliness? Even if the terminology would be used in the strictest and most brutal meaning, i.e., slave must mindlessly follow orders of its master, there is nothing of approval of the real human slavery in the past (or present). This is just the pretty good terminology for such one-sided relationship which is traditionally used in the computer world. By elimination of the word from the world, not a yota changes about the reality of slavery in the past (or present). -1 from me with the extreme violence for introducing such quasi-political nonsense to BPO and wasting everybody's time. |
|
@mcepl: I completely agree with you that we shouldn't waste time with this. I would be better not to dig into the discussion about "master-slave" terminology. IMO we don't even need to go into that as the problem here is more substantial: This case can create a very problematic precedent i.e. _on can modify (even drastically) a well established terminology based on "pseudo-reasons", political opinion or ideology_. IMO this should be stopped and prevented as soon as possible for all sake. On the other hand, I believe the @vstinner is a rational person and he is able to give _rational reasons_ for his decision which other could challenge as "potential offensiveness" of language is not an argument. |
|
This is certainly a topic that generates a lot of opinions both ways, not just here, but on many other projects. Based on that, I don't think it's fair to blame Victor for bringing it up for discussion. This is and has been an industry discussion for many years (master/slave as it relates to technology was named the most politically incorrect term in 2004). Victor simply brought it up here. All of the same arguments and counterarguments have been mentioned in these past discussions. You can argue that this is ridiculous and political correctness has gone too far. You can argue that this term (master/slave) perfectly reflects the model. You can argue that it's not the same relationship as parent/child. These are probably all valid reasons to not change it. But, I think it's mostly because it's what we're used to. Here's an idea -- find a friend and explain to them that there is a concept in computer science where there is a group of 'things' and exactly one of those things is the main point of contact or first in line, but the other things around it that either get direction from that main one, or they are exact copies of that main one, or they are downstream from that main one. Sometimes it's because if the main one isn't available, then one of the others is ready to take its place. Or sometimes it's for other purposes (like IDE). Really set the stage in describing what it is. Then tell them it's called master/slave. They probably won't believe that name because it's a little shocking. We take it for granted, but it doesn't really describe the situation. I know I'm simplifying and I'm probably not 100% accurate, but I think you get my point. Except for the fact that it's imbedded in engineering and computer science and we know it, there's not really a reason for it to be called what it is and there might be other alternatives that are better descriptors. Personally, one that I've never seen suggested, but one that I think can be used to describe the relationship of "one in charge and others follow, but can take over" would be alpha/omega (as in a wolf pack). It's a little stronger that leader/follower, doesn't imply the same structure as parent/child, and allows for the idea that an omega could take over the role of an alpha. Plus, it's very neutral. Just too bad the guys who originally coined the phrase "master/slave" didn't use "alpha/omega". (for the record, political correctness sometimes drives me crazy and I may not see a need to change something like master/slave, but at the same time, I can understand why other people would like to see it changed) (second aside - I don't recall that there were arguments a few months ago on the PR to make the docs gender neutral. Maybe people were against that too as being 'too politically correct', but they didn't feel the need to talk about. To me, this issue is similar to that one.) |
|
Most of the opposition seems to be against a blanket replacing of all master and slave usages, which seems fairly reasonable to me. For example, I'm all for the libregrtest change since it conveys the meaning just as well and is an internal tool. However, changing MemoryView and pty seem way more iffy. These changes are potentially backwards incompatible and actually hurt usability. Unlike other projects, Python doesn't have nearly enough uses of this terminology to warrant a massive political discussion in my opinion. Just look at the usages on a case-by-case basis and be done with it. |
|
I commented here to explain the master <-> view terminology of memoryview. |
|
@cheryl.sabella let me challenge some points in your arguments:
Ok, but where was the discussion? @vstinner didn't even make a point and some of the PRs were merged. Maybe I'm too spoiled by the field where I come from but this can be hardly considered to be "bringing up something for a discussion" when someone doesn't even make a point (like e.g. "I think it should be changed because..."). Ad absurdum I could say: Because of because-it-can-hurt-someones-feelings reasons it would be nice to...
_Personally_, I consider that to be the same kind of PC/SJW nonsense and there should've been a similar discussion. However, there's a big difference. Making documentation gender neutral is unnecessary but it doesn't affect any established CS terminology and doesn't introduce artificial terminological inconsistency between related technologies.
Yes, and that's what is established terminology about.
When you enter a new field a part of your responsibility is to learn its terminology and not voluntarily change it because it somehow affects you (hurts your feelings, not compatible with your political view point etc.). Imagine doing the same thing in physics, chemistry or mathematics. Would you redefine number 1 for diversity reasons (there are ways for making up diversity reasons even for this*)? The terminology used inside a field is primarily for the people who are inside the field and understand it. My arguments can sound a bit sarcastic as they try to illustrate the absurdity of this whole issue. They are by no means personal. Seeing all the PC/SJW nonsense around me, I'm afraid that this can be the starting of Python becoming PCython (by which I don't mean a combination of Python with Cython :)).
|
|
Personally, I find parent/child more descriptive if it can be used in the same context with master/slave, so I'm in favor of replacing master/slave with parent/child where applicable. However, I agree that the code changes in PR 9100 are a bit excessive. It would be nice if we could keep the members of the public API (some of them have already been deprecated) and variable/function/parameter names left out of this cleanup. |
berkerpeksag
added
docs
|
Trying to remove myself from the nosy list again (I know that the interface sometimes surprisingly adds/removes persons). |
|
Mostly, I don't think these changes should be made, particularly in cases where "slave" isn't mentioned at all. The word "master" is used in many contexts where master/slave doesn't apply (such as "master key"). Also, I think the PR disrespects all the original authors of the various documentation entries, none of whom have been consulted. If a particular passage is demonstrably unclear or offensive, it should be changed; otherwise, we shouldn't let vaguely formed notions of political correctness shape other clear uses of plain English. As far as I can't tell there isn't a single instance where the docs use "master" as a reference to human slavery or where the use could be seen to imply an endorsement of that notion. FWIW, Guido drew a line for this a few years ago when someone suggested removing the example using the phrase, "I see said the blind man and he picked up the hammer and saw". The judgment was that we weren't going to go down this path unless there was actual offensive speech. |
|
Indeed, "master" in itself is used in a wide range of contexts and can have quite positive connotations (I master Python programming). The word "slave" I agree with removing if used gratuitously. If its use reflects an established convention which we do not have power to change, then we should probably keep using it for the sake of clarity (for example in the openpty case, since we're merely exposing a glibc function). |
|
I'm closing this now. Three out of four of Victor's PRs have been merged. The fourth one should not be merged because it reflects the underlying terminology of UNIX ptys. There's a remaining quibble about "pliant children" -> "helpers" but that can be dealt with as a follow-up PR without keeping this discussion open. |
|
The discussion under GH PRs is now censored. What will be the next level? |
|
No further discussion needed. This issue has been closed and resolved. Thanks Victor for the PRs. |
|
News about this issue published on different resources are exaggerated. Actually the controversial changes were rejected. All merged changes look correct to me, they fix outdated terminology ("worker" instead of "buildslave" is now the official term in the Buildbot documentation) and make the documentation using more common terminology (for example "parent process" instead of "master process" in context of multiprocessing). |
|
@serhiy.storchaka: IMO, the problem isn't the master/slave terminology itself but the way how the changes were introduced (no discussion) and the justification ("diversity reasons"???). IMO this is the next level: https://bugs.python.org/issue34660 and I can't imagine what comes next. I find this nonsensical and I'm very disappointed that this ideological nonsense is infecting Python. IMO the core developers should make a clear statement about this (either pro or contra). Once it's made, I'll have no other choice than respect that stance and act accordingly. Saying that "there will be not more discussions" or sending people to twitter like Guido did is not a solution and it's rather damaging the Python community and its reputation. :( |
… of a class
If you're using Python 3.9 or above you can directly use the decorators:
```python
class G:
@classmethod
@Property
def __doc__(cls):
return f'A doc for {cls.__name__!r}'
```
If you're not, the solutions are not that good.
perf(git#Change's Controversy): Master to main branch change's controversy
The change is not free of controversy, for example in the [PDM
project](pdm-project/pdm#1064) some people are not sure
that it's needed for many reasons. Let's see each of them:
* *The reason people are implementing the change is because other people are
doing it*: After a quick search I found that the first one to do the change
was [the software freedom conservancy with the Git
project](https://sfconservancy.org/news/2020/jun/23/gitbranchname/). You can
also see [Python](python/cpython#78786),
[Django](django/django#2692),
[Redis](redis/redis#3185),
[Drupal](https://www.drupal.org/node/2275877),
[CouchDB](https://issues.apache.org/jira/browse/COUCHDB-2248) and
[Github](https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main)'s
statements.
As we're not part of the deciding organisms of the collectives
doing the changes, all we can use are their statements and discussions to
guess what are the reasons behind their support of the change. Despite that
some of them do use the argument that other communities do support the
change to emphasize the need of the change, all of them mention that the
main reason is that the term is offensive to some people.
* *I don't see an issue using the term master*: If you relate to this statement
it can be because you're not part of the communities that suffer the
oppression tied to the term, and that makes you blind to the issue. It's
a lesson I learned on my own skin throughout the years. There are thousand
of situations, gestures, double meaning words and sentences that went
unnoticed by me until I started discussing it with the people that are
suffering them (women, racialized people, LGTBQI+, ...). Throughout my
experience I've seen that the more privileged you are, the blinder you
become. You can read more on privileged blindness
[here](https://iveybusinessjournal.com/fighting-privilege-blindness/),
[here](https://dojustice.crcna.org/article/becoming-aware-my-privilege) or
[here](https://www.mindful.org/the-research-on-white-privilege-blindness/)
(I've skimmed through the articles, and are the first articles I've found,
there are probably better references).
I'm not saying that privileged people are not aware of the issues or that
they can even raise them. We can do so and more we read, discuss and train
ourselves, the better we'll detect them. All I'm saying is that a non
privileged person will always detect more because they suffer them daily.
I understand that for you there is no issue using the word *master*, there
wasn't an issue for me either until I saw these projects doing the change,
again I was blinded to the issue as I'm not suffering it. That's because
change is not meant for us, as we're not triggered by it. The change is
targeted to the people that do perceive that `master` is an offensive term.
What we can do is empathize with them and follow this tiny tiny tiny
gesture. It's the least we can do.
Think of a term that triggers you, such as *heil hitler*, imagine that those
words were being used to define the main branch of your code, and that
everyday you sit in front of your computer you see them. You'll probably be
reminded of the historic events, concepts, feelings that are tied to that
term each time you see it, and being them quite negative it can slowly mine
you. Therefore it's legit that you wouldn't want to be exposed to that
negative effects.
* *I don't see who will benefit from this change*: Probably the people that
belongs to communities that are and have been under constant oppression for
a very long time, in this case, specially the racialized ones which have
suffered slavery.
Sadly you will probably won't see many the affected people speak in these
discussions, first because there are not that many, sadly the IT world is
dominated by middle aged, economically comfortable, white, cis, hetero,
males. Small changes like this are meant to foster diversity in the
community by allowing them being more comfortable. Secondly because when
they see these debates they move on as they are so fed up on teaching
privileged people of their privileges. They not only have to suffer the
oppression, we also put the burden on their shoulders to teach us.
As and ending thought, if you see yourself being specially troubled by the
change, having a discomfort feeling and strong reactions. In my experience these
signs are characteristic of privileged people that feel that their privileges
are being threatened, I've felt them myself countless times. When I feel it,
+I usually do two things, fight them as strong as I can, or embrace them, analyze
them, and go to the root of them. Depending on how much energy I have I go with
the easy or the hard one. I'm not saying that it's you're case, but it could
be.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: