Use the default config in the messages documentation tests

[DanielNoord]

• Add yourself to CONTRIBUTORS if you are a new contributor.
• Write a good description on what the PR does.

Type of Changes

	Type
✓	🔨 Refactoring

Description

Will unblock #7070 and others as it changes the value for max-return-values from our own 11 to the default of 6.

[Pierre-Sassoulas]

That's already a great change, but how about we also show the configuration file in the documentation ? That way :

• it's immediately obvious what need to be done to activate the check if it's an extension, or a standard but optional check (soon ™️).
• We can create simpler example by lowering the values to something sane (i.e. max line length = 15 instead of having 120+ character in the example, max-return-values = 2 ...)
• While at the same time demonstrating some options that can affect the message (!)

What do you think ?

[DanielNoord]

That's already a great change, but how about we also show the configuration file in the documentation ? That way :

This can be seen by looking at the examples folder. We would just duplicate the files there.

• We can create simpler example by lowering the values to something sane (i.e. max line length = 15 instead of having 120+ character in the example, max-return-values = 2)

You can use a dedicated pylintrc file for this right?

[Pierre-Sassoulas]

My suggestion is to show this ini configuration in this page : https://pylint.pycqa.org/en/latest/user_guide/messages/warning/bad-builtin.html?highlight=bad-builtin

[DanielNoord]

We already have:
This message is emitted by the optional 'deprecated_builtins' checker which requires the pylint.extensions.bad_builtin plugin to be loaded.
on that page?

[Pierre-Sassoulas]

And then we could add:

bad-functions = ["map", "filter", "something_custom"]

to this, and demonstrate very succinctly how to add new bad builtins.

[DanielNoord]

Let's do that in another PR. There are a lot of moving pieces with that as well:
How to identify related options? How to show the difference between the default value and the value being used in a test? How to handle duplication of the load-plugins warning.

I really intended this PR to unblock some of the PRs that do have correct examples.

[Pierre-Sassoulas]

We already have: This message is emitted by the optional ...

Sure but that's text, and there's two click to reach the possible options. Code that is guaranteed to work alongside with an example is a lot nicer imo.

[Pierre-Sassoulas]

Sure ! Thank you for this, great PR that open a lot of possibilities.

[coveralls]

Pull Request Test Coverage Report for Build 2628103770

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 95.359%

---

Totals
Change from base Build 2625569561:	0.0%
Covered Lines:	16705
Relevant Lines:	17518

---

💛 - Coveralls

[Pierre-Sassoulas]

How to identify related options?

Yeah, that's a problem for us and for user alike 😄

[DanielNoord]

@Pierre-Sassoulas Can you turn on the update branch button on this repository like I have done for pydocstringformatter? It allows easily updating the affected PRs from within the Github interface without pulling them locally.

[Pierre-Sassoulas]

Opened #7143

Can you turn on the update branch button on this repository like I have done for pydocstringformatter?

Sure ! (And I'm still trying to give you the right to do that :) )

[Pierre-Sassoulas]

The option is:

Always suggest updating pull request branches
Whenever there are new changes available in the base branch, present an “update branch” option in the pull request.

But I think it makes it mandatory and we ruled against this because there is a very high number of commit in pylint each day and being forced to update to the latest main was being very harsh on the github actions runners for often no reasons (it's not often that we have incompatible branch). I agree that having to fix a conflict or add a remote locally is very annoying. What do you think ?

[DanielNoord]

Ah yeah, probably best to keep it off. Too bad..

[Pierre-Sassoulas]

For what it's worth I contemplated voluntarily creating conflicts with the online editor so it's possible to merge main from the interface 😄 But now that I'm used to adding remote and removing them right after it's isn't that bad. But it's annoying to not have an option to do that without it being mandatory.

[DanielNoord]

gh pr checkout 7142 works quite well and doesn't add to remote I think.

That said, sometimes I want to fix/merge a PR from the browser and I don't think you can pull/merge main in the online editor (yet).