Some articles about terminology:

• https://tools.ietf.org/id/draft-knodel-terminology-01.html (draft RFC): Master-slave, Blacklist-whitelist and "Other considerations"
• https://www.businessinsider.com/companies-github-terms-master-slave-blacklist-whitelist-open-source-2020-6
• https://www.marketplace.org/2020/06/17/tech-companies-update-language-to-avoid-offensive-terms/
• https://www.washingtonpost.com/opinions/2020/06/12/tech-industry-has-an-ugly-master-slave-problem/
• https://lifehacker.com/ditch-these-racist-terms-from-your-tech-vocabulary-1844041452
• etc.

I will not attempt to give an exhaustive list of articles, it's a hot topic and there are more and more articles about that!

• tools.ietf.org/id/draft-knodel-terminology-01.html (draft RFC): Master-slave, Blacklist-whitelist and "Other considerations"

Newest draft is v3 (July 08, 2020):

• https://tools.ietf.org/id/draft-knodel-terminology-03.html

Edit: now at v4 (August 24, 2020):

• https://tools.ietf.org/id/draft-knodel-terminology-04.html

"Inclusive Chromium code": https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md

Are the guides moving to "allowlist"/"denylist"? I've seen "allow list"/"deny list" (notice the spaces). I've also seen "block list".

I don't think that we have to require one replacement. We can suggest multiple alternatives. For example, first I replaced blacklist with denylist in http.cookiejar documentation, but when I read again the whole documentation, it seems like blocklist is more appropriate: python/cpython#21826

I agree that it is reasonable to enumerate terms that should be avoided. As always, the peanut gallery (itself an economically loaded term) is likely to chime in and tell us we're all wrong for trying to do the right thing, but it is important that we persist.

I've been seeing allowlist/blocklist as an accepted replacement terminology pretty broadly across my professional security-oriented network. I like it because I find it unambiguous, and "block" has slightly stronger connotations than "deny" in parallel usage. For better or worse, it's also verbally similar enough to allow for seamless substitution and general comprehension among folks who haven't thought carefully about the issue.

For "master/slave" replacement I have a personal preference for "leader/follower" in cases where it semantically fits. It's clear, makes fewer assumptions about western nuclear family structure than "parent/child", and avoids the abiguity associated with "server/client" where "client" is a potential leader but just happens to be following (in contrast to "client" in the "queries the data store" sense).

[and not to go down a rabbit hole, but "client" can also be problematic given the feudal connotations]

More generally, I think it is helpful to enumerate specific turns of phrase to be avoided, since we otherwise risk falling to an onslaught of malintentioned arguers with a goal of derailing improvements via reductio ad absurdum. [yes, etymology is problematic with this phrasing too]

I suggest this wording:

The Python community welcomes all. We avoid language associated with opposition to this goal.

@vstinner

master/slave => parent/child, server/client, main, primary/seconday, etc.
whitelist/blacklist => allowlist/denylist, ignore, etc.

+1 For the proposed replacements. It might be a decent idea to put together a table in the devguide (perhaps in the "Documentating Python" section). My only feedback would be to use some caution with regards to banning the usage of terms that are not widely considered to be controversial, so that we don't end up spending an infinite amount of time on this.

I'm personally of the mindset that there are definitely outdated terms that we should move away from ("master/slave" and "blacklist/whitelist" being some of the more egregious offenders), but that it's impossible to avoid making someone out there uncomfortable; e.g. I'd have to disagree with @PaulMcMillan about avoiding usage of "parent/child" and "server/client". If you dig deep enough, there are going to be some potential connotations with any terminology. To me at least, those connotations have to be adequately clear and severe enough to justify the time spent replacing them (and of course, the replacement should be just as clear if not more clear than the original). Otherwise, the maintenance cost starts to outweigh the benefits, especially if it is determined that the replacements are offensive to someone a few years down the road.

At work we are avoiding "master", "slave", "blacklist", and "whitelist" and I have heard the same from other companies. I think that's good for now and if other teams come out as generally unacceptable we can handle them then.

FYI there was a discussion about the usage of gendered language in the PEP 3136: https://bugs.python.org/issue41743

I agree overall on a list of inclusive languages, but I'm not sure if the devguide is the right place for it. I think perhaps this could fall within the scope for the upcoming Docs WG, to provide a guideline of acceptable terms. I would hope we use those terminologies not just for writing documentation, comments, code, but also during normal communications like in mailing lists/discussion forums.

I agree overall on a list of inclusive languages, but I'm not sure if the devguide is the right place for it.

Do you have a better place for such list?

The Docs WG doesn't exist yet, so devguide can a temporary home, until it is moved to somewhere else.

Are we in such a rush to have an allowlist of terms that we can't wait for the Docs WG?

I don't think that we have to require one replacement. We can suggest multiple alternatives.

Agree, as a french speaker I'm glad when alternatives are proposed (building it myself in my brain take efforts, I miss some, and it take time). Multiple alternatives is good too, so we can pick the most relevant one according to the context (which is often more semantically right than the avoided terms).

The Docs WG doesn't exist yet, so devguide can a temporary home, until it is moved to somewhere else.

Agree, the https://devguide.python.org/documenting/ is a good place for those recommendations. (nobody denies the Docs WG to edit this page), it's not like we're creating a whole new thing.