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:

* https://github.com/antirez/redis/issues/3185
* https://www.drupal.org/node/2275877
* https://issues.apache.org/jira/browse/COUCHDB-2248
* https://github.com/django/django/pull/2692

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:

* Git "master" branch
* "webmaster"
* "postmaster"

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.

The doctest module has doctest.master symbol:
---
# For backward compatibility, a global instance of a DocTestRunner
# class, updated by testmod.
master = None
---

I'm not sure about changing this one. Here there is no slave, so it's less confusing.

But more generally, maybe it's time to remove this deprecated variable only kept for backward compatibility?

Tkinter and IDLE are full of "master" variables:

   master: parent for widgets.

It seems to be a keep concept of Tkinter windows.

nntplib.NNTP() has a slave() method, but this method sends a "SLAVE" command to the NNTP server. Changing that would require to modify the NNTP protocol, that's out of the scope of this issue...

RFC 977 "Network News Transfer Protocol" (NNTP)
Section 3.12: The SLAVE command
https://tools.ietf.org/html/rfc977

In the C API, PyMemoryViewObject has a mbuf.master attribute, Include/memoryview.h:

---
typedef struct {
    PyObject_HEAD
    int flags;          /* state flags */
    Py_ssize_t exports; /* number of direct memoryview exports */
    Py_buffer master; /* snapshot buffer obtained from the original exporter */
} _PyManagedBufferObject;


/* memoryview state flags */
#define _Py_MEMORYVIEW_RELEASED    0x001  /* access to master buffer blocked */
#define _Py_MEMORYVIEW_C           0x002  /* C-contiguous layout */
#define _Py_MEMORYVIEW_FORTRAN     0x004  /* Fortran contiguous layout */
#define _Py_MEMORYVIEW_SCALAR      0x008  /* scalar: ndim = 0 */
#define _Py_MEMORYVIEW_PIL         0x010  /* PIL-style layout */

typedef struct {
    PyObject_VAR_HEAD
    _PyManagedBufferObject *mbuf; /* managed buffer */
    Py_hash_t hash;               /* hash value for read-only views */
    int flags;                    /* state flags */
    Py_ssize_t exports;           /* number of buffer re-exports */
    Py_buffer view;               /* private copy of the exporter's view */
    PyObject *weakreflist;
    Py_ssize_t ob_array[1];       /* shape, strides, suboffsets */
} PyMemoryViewObject;
---

sqlite3.dump._iterdump() access to the "sqlite_master" table.... Hum, I don't think that Python chose the name of this table. This issue should be addressed in SQLite, not in Python.

nis module contains the error message: NisError("No NIS master found for any map"), but libnis has a yp_master() function, it's no like Python picked this name. I suggest to keep "master" here to keep Python consistent with libnis. And "NIP master" gives the context of the "master" term.

(Oops, I didn't want to put so many people in the nosy list, sorry about the spam.)

Ok, with these 3 PRs, I should have replaced most usages of master and slave terms.

New changeset 012f5b968a738b15ae9b40c499a1c0778b0615a9 by Victor Stinner in branch 'master':
bpo-34605, libregrtest: Rename --slaveargs to --worker-args (GH-9099)
https://github.com/python/cpython/commit/012f5b968a738b15ae9b40c499a1c0778b0615a9

> bpo-34605, libregrtest: Rename --slaveargs to --worker-args (GH-9099)

I don't think that this change should be backported to 3.7 and older, since it *might* break the backward compatibility.

Just want to add that it's a constant source of problem with respect to Redis and antirez wrote a detailed blog post about it yesterday : http://antirez.com/news/122 . It causes a lot of energy and emotional drain when issues like this get to twitter and top pages of HN : https://twitter.com/antirez/status/1037809132303208455

Thanks

New changeset 5e922658fb55734bf8b4c6246033ea93af172ff7 by Victor Stinner in branch 'master':
bpo-34605: Avoid master/slave terms (GH-9101)
https://github.com/python/cpython/commit/5e922658fb55734bf8b4c6246033ea93af172ff7

New changeset 7e610bcdf128f61b925654e4fa80fbac83537d0e by Victor Stinner in branch 'master':
bpo-34605: childs => children (GH-9102)
https://github.com/python/cpython/commit/7e610bcdf128f61b925654e4fa80fbac83537d0e

I'm a little surprised by this.  It's not like slavery was acceptable when these computer science terms were coined and it's only comparatively recently that they've gone out of fashion.  On the other hand, there are some areas in computer software where "master" and "slave" are the exact technical terms (e.g. IDE), and avoiding them would lead to confusion.

Of the four citations you reference, one of them is a PR for Django, and three of them say "see the Django PR".  The Django PR is an unreadable infinitely-long page of miserable arguing.  So the context doesn't help much.

Have there been any actual complaints?  Or is this an attempt to solve a problem that doesn't really exist?

As a counter-example: A quick grep finds 555 occurrences of the word "kill" in CPython master.  Everybody knows killing is bad and using the term might upset certain people.  Yet I would not support expunging the word "kill" from Python.

> Have there been any actual complaints?

Yes, but sadly they are private.

> The Django PR is an unreadable infinitely-long page of miserable arguing.  So the context doesn't help much.

In short, some people associate the words "master" and "slave" to slavery. To enhance the diversity in the Python community, I suggest to try to avoid these terms whenever possible. As I wrote in previous comments, it seems like we have to keep them in a few places.

> > Have there been any actual complaints?
> Yes, but sadly they are private.

I'm not super-excited by the idea that Python has to change its behavior based on secret comments.  Python has traditionally had a very open governance model where all discussions happen in public.

While I understand the need to preserve the privacy of victims, is there some way we can bring the decision-making process out into the open?  As far as I can tell, the entire process so far has been "Victor concludes that these terms are bad, and creates and merges several PRs an hour or two later with zero discussion".

Perhaps the complaints could be edited to anonymize them, and then we could see them?  Or must Python change its governance model because of diversity concerns?

Not all uses of the word "master" are associated with slavery, e.g. "master craftsman", "master copy", "master file table".

I think it's best to avoid use of master/slave where practicable, but other uses of "master" are not necessarily a problem.

To me, there is nothing wrong with the word 'master', as such.  I mastered Python to become a master of Python.  Purging Python of 'master' seems ill-conceived.  The word 'slave' is different matter to me.

In tk and tkinter, the 'parent' and 'master' of a widget may be different widgets, but I cannot remember the functional difference, nor whether the terms are used consistently.

Like Larry, I object to action based on hidden evidence.

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 
source from which all copies will be produced"):

   https://en.wikipedia.org/wiki/Audio_mastering

The ManagedBufferObject is literally the source from which all views 
are produced.

Conductors are sometimes called "Maestro", there are chess grandmasters, 
Tiger Woods won the Masters Tournament, Art Tatum is called a master 
pianist, millions of people hold a master's degree.

The term "master" has so many positive connotations that I think it is 
misguided to effectively eliminate it from the current English language.

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.

@vstinner:

> For diversity reasons, it would be nice to try to avoid "master" and "slave" terminology which can be associated to slavery.

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. 
If anyone wants to change that, please open a separate issue and add me as 
the author to the nosy list.

@cheryl.sabella let me challenge some points in your arguments:

> Based on that, I don't think it's fair to blame Victor for bringing it up for discussion.

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

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

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

> But, I think it's mostly because it's what we're used to.

Yes, and that's what is established terminology about.

> Here's an idea -- find a friend and explain to them that there is a concept in computer science...

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 :)).

* To see how far could this go, look at this video: https://www.youtube.com/watch?v=iKcWu0tsiZM

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.

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.

New changeset fa7dfae3171914f91d629a64c6e829788b485b06 by Miss Islington (bot) (Victor Stinner) in branch 'master':
bpo-34605: Replace "pliant children" with "helpers" (GH-9195)
https://github.com/python/cpython/commit/fa7dfae3171914f91d629a64c6e829788b485b06

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. :(

New changeset 8a73cac618a050f4e74eb38ff43e48d9957a6dec by Victor Stinner in branch '3.7':
[3.7] bpo-34279: Synchronize regrtest with master (GH-10800)
https://github.com/python/cpython/commit/8a73cac618a050f4e74eb38ff43e48d9957a6dec

New changeset 43d812692f9207520e1169ff88cd8d6c59cc4804 by Miss Islington (bot) in branch '3.6':
[3.7] bpo-34279: Synchronize regrtest with master (GH-10800)
https://github.com/python/cpython/commit/43d812692f9207520e1169ff88cd8d6c59cc4804