Issue 41521: Replace whitelist/blacklist with allowlist/denylist

I propose to replace whitelist/blacklist with allowlist/denylist. The terms whitelist and blacklist can be associated to color skins which isn't the intent. To avoid confusion, I propose to use neutral terms: allowlist and denylist. Moreover, as a french person (english is not my first language, but french), "allow" and "deny" are even more explicit to me than "white "and "black".

The intent is to make the Python community more welcoming and more diverse by avoiding to make some people uncomfortable.

Many other projects already replaced whitelist/blacklist with allowlist/denylist:

* GitLab: https://gitlab.com/gitlab-org/gitlab/-/issues/7554
* React: https://github.com/facebook/react/commit/8a8d973d3cc5623676a84f87af66ef9259c3937c
* Mediawiki: https://phabricator.wikimedia.org/T254646
* GitHub: https://thenextweb.com/dd/2020/06/15/github-plans-to-replace-racially-insensitive-terms-like-master-and-whitelist/
* Google Chrome: https://9to5google.com/2020/06/12/google-android-chrome-blacklist-blocklist-more-inclusive/
* etc.

See also:

* Carolyn Stransky's "Humanizing Your Documentation" presentation:
https://speakerdeck.com/carolstran/humanizing-your-documentation-full-talk
* bpo-34605: "Avoid master/slave terminology"

Attached PRs replace whitelist/blacklist with allowlist/denylist.

+1

New changeset fabd7bb8e0450f16ed5c5c0ad575aa413d65712d by Victor Stinner in branch 'master':
bpo-41521: Replace whitelist/blacklist with allowlist/denylist (GH-21822)
https://github.com/python/cpython/commit/fabd7bb8e0450f16ed5c5c0ad575aa413d65712d

New changeset 0ee0b2938cb606151d8d287472c838044bad4a0e by Victor Stinner in branch 'master':
bpo-41521: Replace whitelist/blacklist with allowlist/denylist (GH-21823)
https://github.com/python/cpython/commit/0ee0b2938cb606151d8d287472c838044bad4a0e

"While the etymology of the words isn't steeped in racial undertones or history like other problematic tech word choices, there is no harm in changing them to synonyms that as just as understandable and avoid the question entirely"

https://web.archive.org/web/20180921225759/https://github.com/facebook/react/issues/13604#issuecomment-419884422

Another rationale from "Inclusive Chromium code":

Terms such as “blacklist” and “whitelist” reinforce the notion that black==bad and white==good. That Word Black, by Langston Hughes illustrates this problem in a lighthearted, if somewhat pointed way. These terms can usually be replaced by “blocklist” and “allowlist” without changing their meanings, but particular instances may need other replacements.

https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md

Should not such changes be widely discussed on the Python-Dev mailing list before merging?

New changeset 0e95bbf08571e98f4b688524efc2dcf20d315d91 by Victor Stinner in branch 'master':
bpo-41521, typing: Rename _PROTO_WHITELIST to _PROTO_ALLOWLIST (#21825)
https://github.com/python/cpython/commit/0e95bbf08571e98f4b688524efc2dcf20d315d91

Serhiy:
> Should not such changes be widely discussed on the Python-Dev mailing list before merging?

I would prefer avoiding python-dev, since there are many trolls there who like to argue but not try to fix problem. See the recent discussion about the PEP 8 commit message for example.

I opened https://github.com/python/devguide/issues/605 to define general guidelines about terminology.

New changeset 20ae565bd2d79425d5567c001ed8f89848d7d907 by Victor Stinner in branch 'master':
bpo-41521: Replace denylist with blocklist is http.cookiejar doc (GH-21826)
https://github.com/python/cpython/commit/20ae565bd2d79425d5567c001ed8f89848d7d907

> I would prefer avoiding python-dev, since there are many 
> trolls there who like to argue but not try to fix problem.

It's not a good precedent to define as trolls anyone who might legitimately disagree, nor is it a good precedent to bypass discussion entirely. IMO, Serhiy's request was reasonable and shouldn't be dismissed.

For this particular change, I'm +1 because it represents an industrywide terminology shift, because it makes a proactive effort to be responsive to cultural problems, and because the change doesn't impair clarity.  

That said, I concur with Serhiy that there should be a discussion before making a unilateral and stealthy change to the rules about how people are allowed to write technical prose.

> That said, I concur with Serhiy that there should be a discussion before making a unilateral and stealthy change to the rules about how people are allowed to write technical prose.

I suggest you to join the discussion there:
https://github.com/python/devguide/issues/605

New changeset fbf43f051e7bf479709e122efa4b6edd4b09d4df by Victor Stinner in branch 'master':
bpo-41521: Rename blacklist parameter to not_exported (GH-21824)
https://github.com/python/cpython/commit/fbf43f051e7bf479709e122efa4b6edd4b09d4df

I don't think that it's worth it to backport these changes, so I close the issue.

Again, to avoid reintroducing such terms, I proposed https://github.com/python/devguide/issues/605 to define some general guidelines on the terminology.

Thanks for reviews.

stage: patch review -> resolved