False positive unspecified-encoding when passing encoding as kwarg

[jamesbraza]

Bug description

When passing an encoding as a kwarg to open, I get unspecified-encoding thrown.

CSV_KWARGS = {"newline": "", "encoding": "utf-8"}
with open("foo.csv", **CSV_KWARGS):
    pass

Configuration

No response

Command used

pylint --score=false a.py

Pylint output

************* Module quick_play
a.py:2:5: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)

Expected behavior

I think it would be cool if pylint wouldn't throw unspecified-encoding in this case.

Pylint version

pylint 2.17.4
astroid 2.15.4
Python 3.10.10 (main, Feb 19 2023, 17:57:18) [Clang 14.0.0 (clang-1400.0.29.102)]

OS / Environment

macOS Monterey v12.6

Additional dependencies

No response

[crazybolillo]

I briefly reviewed the code involved and it seems there are two places where a fix could be applied. Either in the checker itself or in utils.get_argument_from_call which is what it uses to retrieve the encoding argument.

Modifying get_argument_from_call to take into account **kwargs when a keyword argument is requested seems nice, but I don't know if it is too big of a change for stable.

[crazybolillo]

Ok, it seems the actual problem is being able to get the kwargs from the function call. The astroid node only contains the name of the variable used (in the example above CSV_KWARGS), but not its definition (the value it contains).

[Pierre-Sassoulas]

In order to get the actual values we'll have to use inference. I think we need to make sure we use inference only if absolutely necessary because of the performance impact and the fact that using a dict to pass arguments to open is far from the primary way to do it.

[crazybolillo]

Ah, inference is a nice thing, learnt something new. I made #8728 which puts it to the test. Let me know if I can do anything else to be of help.