[issue34605] Avoid master/slave terminology

[miss-islington]

miss-islington  added the comment:


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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[miss-islington]

Change by miss-islington :


--
pull_requests: +10050

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:


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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +10047

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Socob]

Change by Socob <206a8...@opayq.com>:


--
nosy: +Socob

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Gabriel Marko]

Change by Gabriel Marko :


--
nosy:  -suic

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Gabriel Marko]

Gabriel Marko  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

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

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

No further discussion needed. This issue has been closed and resolved. Thanks 
Victor for the PRs.

--
nosy: +Mariatta

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Gabriel Marko]

Gabriel Marko  added the comment:

The discussion under GH PRs is now censored. What will be the next level?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Giampaolo Rodola']

Change by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[miss-islington]

miss-islington  added the comment:


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


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +8631

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Guido van Rossum]

Guido van Rossum  added the comment:

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.

--
nosy: +gvanrossum
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Antoine Pitrou]

Antoine Pitrou  added the comment:

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

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Raymond Hettinger]

Raymond Hettinger  added the comment:

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.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Matej Cepl]

Change by Matej Cepl :


--
nosy:  -mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Stefan Krah]

Change by Stefan Krah :


--
nosy:  -skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Stefan Krah]

Stefan Krah  added the comment:

Trying to remove myself from the nosy list again (I know that the interface 
sometimes surprisingly adds/removes persons).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Berker Peksag]

Berker Peksag  added the comment:

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.

--
components: +Documentation
nosy: +berker.peksag
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Gabriel Marko]

Gabriel Marko  added the comment:

@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

--
nosy: +skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Stefan Krah]

Stefan Krah  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Stefan Krah]

Change by Stefan Krah :


--
nosy:  -skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Ammar Askar]

Ammar Askar  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Cheryl Sabella]

Cheryl Sabella  added the comment:

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

--
nosy: +cheryl.sabella

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Gabriel Marko]

Gabriel Marko  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Matej Cepl]

Matej Cepl  added the comment:

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.

--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Eric V. Smith]

Change by Eric V. Smith :


--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Gabriel Marko]

Gabriel Marko  added the comment:

@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?

--
nosy: +suic

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Steven D'Aprano]

Steven D'Aprano  added the comment:

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.

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Stefan Krah]

Stefan Krah  added the comment:

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.

--
nosy: +skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Terry J. Reedy]

Terry J. Reedy  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Terry J. Reedy]

Terry J. Reedy  added the comment:

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.

--
nosy: +terry.reedy -mrabarnett

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Matthew Barnett]

Matthew Barnett  added the comment:

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.

--
nosy: +mrabarnett

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Larry Hastings]

Larry Hastings  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

> Have there been any actual complaints?

Yes, but sadly they are private.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Larry Hastings]

Larry Hastings  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Larry Hastings]

Larry Hastings  added the comment:

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?

--
nosy: +larry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:


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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +8556

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:


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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

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

--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:


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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

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

--
nosy:  -Alex.Willmer, asvetlov, barry, docs@python, dstufft, eric.araujo, 
ezio.melotti, koobs, larry, mrabarnett, ned.deily, paul.moore, r.david.murray, 
ronaldoussoren, steve.dower, terry.reedy, tim.golden, zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

Change by STINNER Victor :


--
components:  -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, 
Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, 
FreeBSD, IDLE, IO, Installation, Library (Lib), Regular Expressions, SSL, 
Tests, Tkinter, Unicode, Windows, XML, ctypes, email, macOS

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +8555

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Yury Selivanov]

Change by Yury Selivanov :


--
components:  -asyncio
nosy:  -yselivanov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

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_RELEASED0x001  /* 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;
---

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

Tkinter and IDLE are full of "master" variables:

   master: parent for widgets.

It seems to be a keep concept of Tkinter windows.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Ammar Askar]

Ammar Askar  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

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/'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +8553
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +8554

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

STINNER Victor  added the comment:

I'm working on patches to change that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[Ammar Askar]

Ammar Askar  added the comment:

Do you have examples of where this occurs? 

>From 
>https://github.com/python/cpython/search?p=1=master+slave_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.

--
nosy: +ammar2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34605] Avoid master/slave terminology

[STINNER Victor]

New submission from STINNER Victor :

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

--
assignee: docs@python
components: 2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, 
Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, 
FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular 
Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, 
email, macOS
messages: 324739
nosy: Alex.Willmer, asvetlov, barry, docs@python, dstufft, eric.araujo, 
ezio.melotti, koobs, larry, mrabarnett, ned.deily, paul.moore, r.david.murray, 
ronaldoussoren, steve.dower, terry.reedy, tim.golden, vstinner, yselivanov, 
zach.ware
priority: normal
severity: normal
status: open
title: Avoid master/slave terminology
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com