sys.argv is inferred wrongly as pylint's own values for sys.argv instead of Uninferrable

[MarcoGorelli]

Bug description

Make file t.py

import sys

a, b, c = sys.argv

print(a, b, c)

and run python t.py 1 2

Configuration

No response

Command used

pylint t.py

Pylint output

$ pylint t.py
************* Module t
t.py:1:0: C0114: Missing module docstring (missing-module-docstring)
t.py:3:0: W0632: Possible unbalanced tuple unpacking with sequence: left side has 3 label(s), right side has 2 value(s) (unbalanced-tuple-unpacking)

------------------------------------------------------------------
Your code has been rated at 3.33/10 (previous run: 0.00/10, +3.33)

Expected behavior

The W0632 on line 3 looks like a bug, as in this case sys.argv is ['t.py', '1', '2']

Pylint version

$ pylint --version
pylint 2.15.5
astroid 2.12.12
Python 3.10.6 | packaged by conda-forge | (main, Aug 22 2022, 20:35:26) [GCC 10.4.0]

OS / Environment

$ uname -a
Linux DESKTOP-U8OKFP3 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Additional dependencies

No response

[Pierre-Sassoulas]

pylint a.py --enable=all --enable-all-extensions on the same code gives: left side has 3 label(s), right side has 4 value(s), so we infer the right value of sys.argv with the value given to pylint but it make no sense as we can't know what will be inside sys.argv when the code will be launched. We need to do a special case for this, and we might still raise a message like "Possible unbalanced tuple unpacking: we can't know what will be in sys.argv in advance".

[clavedeluna]

We need to do a special case for this, and we might still raise a message like "Possible unbalanced tuple unpacking: we can't know what will be in sys.argv in advance".

This can still be a unbalanced-tuple-unpacking msg but we can somehow pass the extra msg "we can't know what will be in sys.argv in advance" as an arg, right?

[Pierre-Sassoulas]

Maybe astroid needs to raise an inference error on sys.argv. That would be more accurate and also probably fix pylint in this particular case because if we can't infer we don't raise to avoid false positives.

[eli-schwartz]

I think it definitely makes sense to not report an error here. The workaround to quell the error is replacing a, b, c = sys.argv with a = sys.argv[0]; b = sys.argv[1]; c = sys.argv[2], and there's no error for accessing indexes that may not exist...

Maybe related: my first attempt to solve this was: foo, bar = sys.argv[1:3], which is quite explicit that there must be enough values there. Pylint doesn't detect that the right side has two values (or else will ValueError: not enough values to unpack at runtime). Instead it still tells me that "right side has 1 value". :D I would have expected the explicit slicing to result in a defined sequence with known length.

[Pierre-Sassoulas]

This require a change in astroid to infer correctly sys.argv as uninferrable.

Using argv directly instead of letting argparse or click or a new fancy parsing library I never heard about do the parsing could be another check in itself imo : if sys.argv is accessed directly it means you're not going to have the same level of support for errors than a dedicated library, and argparse is a builtin lib since python 3.2.

[eli-schwartz]

Yup, agreed.

That aligns with my use case: if I was writing a tool that needed to do parsing of user arguments I'd use argparse or optparse because stdlib, but in this case I actually want to generate a script at runtime and then execute it with a different python interpreter than the current one. It's not user facing, I always know exactly how many arguments are internally passed, so I feel confident in not bothering with even checking the length, let alone using named flag-arguments.

[Timmmm]

This was a very frustrating to debug. Adding an extra Python file to my project caused this error in a completely different Python file that previously was fine.

I would disable it by default until this is fixed.