Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto-upgrade the whitelist and blacklist options in configuration #5465

Open
Talador12 opened this issue Dec 3, 2021 · 11 comments
Open

Auto-upgrade the whitelist and blacklist options in configuration #5465

Talador12 opened this issue Dec 3, 2021 · 11 comments
Labels
Blocked 🚧 Blocked by a particular issue Configuration Related to configuration Enhancement ✨ Improvement to a component

Comments

@Talador12
Copy link

Talador12 commented Dec 3, 2021

Current problem

In .pylintrc we have the following attribute

extension-pkg-whitelist=

For context, here is a description of that

# A comma-separated list of package or module names from where C extensions may
# be loaded. Extensions are loading into the active Python interpreter and may
# run arbitrary code. (This is an alternative name to extension-pkg-allow-list
# for backward compatibility.)

At what point do we end backwards compatibility on this term? It is worth deprecating that language at some point.

Desired solution

We should deprecate extension-pkg-whitelist in favor of extension-pkg-allow-list for all references

Additional context

Lots of different inclusivity guides out there, but here's one
https://developers.google.com/style/inclusive-documentation

@Talador12 Talador12 added Enhancement ✨ Improvement to a component Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling labels Dec 3, 2021
@Talador12
Copy link
Author

If anyone can find other references of language that should be deprecated, please add examples to this ticket.

@Talador12 Talador12 changed the title Insclusive language update Inclusive language update Dec 3, 2021
@Pierre-Sassoulas
Copy link
Member

This has been answered in detail in the initial MR, in particular here and here:

We're never going to break compatibility for the old name. That would be forcing maintenance work on pylint users for political reasons.

So to do that partially would requires #5462. You're welcome to contribute to it if you like.

@Pierre-Sassoulas Pierre-Sassoulas added Documentation 📗 and removed Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling labels Dec 3, 2021
@Talador12
Copy link
Author

I disagree that this would be considered political reasons as this is more about ethics than politics. I will add to #5462

@Talador12
Copy link
Author

Talador12 commented Dec 3, 2021

@Pierre-Sassoulas One more case to consider

pylintrc uses [MASTER] at the top of the file. Could this be changed to [MAIN] ? Currently it appears to only allow [MASTER]. We can keep the backwards compatibility if that is the stance of pylint.

@Pierre-Sassoulas
Copy link
Member

Please read the initial MR provided and the two comments linked in particular.

@Talador12
Copy link
Author

I had read the MR and two comments you had linked.

Confirmed that an updated pylint version has [MAIN] compatibility.

However, I did notice that pylint --generate-rcfile still uses [MASTER] terminology by default.

Since [MAIN] is compatible, it should be the default for pylint --generate-rcfile going forward.

@Pierre-Sassoulas
Copy link
Member

No. Please take the time to read the existing discussion properly. You previously answered that you disagreed in 4mn so clearly you did not. You also misunderstood what you read the second time around. A config file with '[main]' instead of '[master]' would not work right now. The following is still true:

Changing the "master" in the options and configuration would break compatibility with all the pylint configuration files ever written. This would impact a huge amount of person and would make a lot of documentation and question on stackoverflow and everywhere else obsolete. [...] it need to be done as a breaking change for 3.0. I expect those kind of changes to be included in a big refactor of the configuration and option parser to use something modern like click or argparse and pyproject.toml that would affect pylint, but also pylint integration in emacs and other editor.

See #5392 and #5462

@pylint-dev pylint-dev locked as spam and limited conversation to collaborators Dec 3, 2021
@pylint-dev pylint-dev unlocked this conversation May 10, 2022
@DanielNoord
Copy link
Collaborator

I have put in a a PR to fix #5467.

I'm going to refocus this issue to deprecating whitelist and blacklist. For any other language updates please open separate issues. Please keep those very specific about issues you have identified instead of a larger call for "examples to deprecate". 😄

@DanielNoord DanielNoord changed the title Inclusive language update Deprecate the whitelist and blacklist options May 10, 2022
@DanielNoord DanielNoord added Configuration Related to configuration and removed Documentation 📗 labels May 10, 2022
@Pierre-Sassoulas
Copy link
Member

Wasn't this particular issue fixed in #3961 ?

@DanielNoord
Copy link
Collaborator

Partially, we now offer support for the new options but the suggestion in this issue is to deprecate the old options (and then remove them in a later version).
With the new_names stuff added with argparse we can now actually deprecate options so this is something we can do. We already did the same for black_list.

@Pierre-Sassoulas
Copy link
Member

Blocked by #5462

@Pierre-Sassoulas Pierre-Sassoulas changed the title Deprecate the whitelist and blacklist options Auto-upgrade the whitelist and blacklist options in configuration Jul 3, 2022
@Pierre-Sassoulas Pierre-Sassoulas added the Blocked 🚧 Blocked by a particular issue label Jul 3, 2022
@DanielNoord DanielNoord removed their assignment Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Blocked 🚧 Blocked by a particular issue Configuration Related to configuration Enhancement ✨ Improvement to a component
Projects
None yet
Development

No branches or pull requests

3 participants