To explain why I'm against this change:

1. This is a large breaking change as it changes the behaviour of how pylint is invoked. The benefit is that you wouldn't need to type " .", which is minimal in my opinion and therefore does not warrant such a large breaking change.
2. Arguably, this is also incorrect as when a user invokes pylint without any directories are files as argument we don't know what we're supposed to lint. We can make the assumption that it should be the current directory, like this proposal does, but I don't think we should make assumptions like that.

I prefer the approach mypy takes which supports a files option in the configuration file which, when set, then allows invoking mypy without any other arguments. In that case the files argument is already set in the configuration.

Benefits of this approach are that it would be non breaking (the behaviour would only change when files is set, which would only be so for user that have updated their configuration) and not make any assumptions about users' intentions.
The only additional effort required by the user is to set that files option once.

@DanielNoord just to make sure I understand your suggestion:
You suggest to add a new optional entry called files or files_default in setup.cfg under [options] and set the . there? something like:

[options]
files = .:

This way when the user invoke pylint with no args it would be equivalent to pylint .?
and if the user wants to run specific files or directory he can without breaking old behavior?

Yes. If you specify the files option on the command line it would overwrite whatever is in setup.cfg as it has higher priority. You could specify project/subdir if you're only ready to run pylint over a sub directory.
Technically we already support the files option: the arguments passed on the command line that do not fit in any other option are read as files, but we do not support adding it to your config file.

This is what I'm doing at the moment for pylint to work on my entire project:
pylint --score=n --output-format=colorized $(git ls-files 'backend/*.py')

Looks like pylint --recursive=y . now does the trick since v2.13.0. See: #352.

I'd support it, if I could figure out a way to exclude directories like .venv/ - despite "documentation" and fixes, I've just spent an hour trying to figure out how to exclude that directory, without success.

There's an ignore option and ignore-patterns option. First search result for "pylint exclude directory" : https://stackoverflow.com/questions/2503717/. Please open a new issue to tell us how can we make the documentation better :) (Edit: #6471 needs to be fixed)

@Pierre-Sassoulas actually the option you need is --ignore-paths .

@yaleman Try --ignore-paths='.venv'

I have a solution for this in #7496 that is non-breaking. Anybody who is looking for this feature is more than welcome to test it out and give feedback. This is crucial behaviour so I'm very wary of any backward incompatible changes, ironing those out before release is crucial.

In absence of configuration, pylint and pylint . should do the same. Still, when configuration exists, . should override whichever default value was configured inside the config.

Another example is that pylint without arg should allow it to find its config in parent directories and run from there.

PS. I maintain several linters.

With 85% in favor (45 👍 , 8 👎 as of 2023-03-09 after this issue being pinned for 14 months), pylint will be equivalent to pylint . in 3.0.0.

Moving milestone to 4.0.0 because we want to release a new version of pylint on time for python 3.12 release on 2023-10-02 and supporting python 3.12 in a 2.X branch is not reasonable.