I'm confused as to why a local pylint check ignores the following error, but an apparently identical pylint check as part of a GitHub Actions workflow raises a syntax error.
I have a small Python test script containing the following deliberately incorrect line 55:
print(f"Why isn't this highlighted? {getenv("PATH","notfound")}")
If I upload the file to GitHub using a GitHub Actions validation workflow which includes a pylint -E check, I get the following error as expected:
Run pylint -E src
************* Module sandpit.main
src/sandpit/main.py:55:47: E0001: Parsing failed: 'f-string: unmatched '(' (sandpit.main, line 55)' (syntax-error)
Error: Process completed with exit code 2.
Removing the embedded double-quotes resolves the issue, as expected:
print(f"Why isn't this highlighted? {getenv('PATH','notfound')}")
But if I run a local pylint check in my VSCode IDE using exactly the same version of pylint and (as far as I am aware) the same configuration options, the original syntax error is not highlighted and the line is accepted and executes without difficulty. Ideally I'd like the local pylint check to highlight the error.
Any clues as to why this might be happening? Is there some subtle difference in configuration options that I might be missing?
I've tried with different Python versions from 3.8 to 3.12, but get the same behaviour in all. The only pylint command line option I'm using is the -E flag and AFAICS there's nothing in my local IDE configuration that would suppress a pylint E0001 error.
Python 3.12 is the first version to accept such quotation in f-strings. Before 3.12 it was a syntax error (as seen in GitHub), and after 3.12 it's perfectly ok.
The pylint error you're seeing is pylint failing to parse the file, not a lint message. There doesn't seem to be any lint rules against this syntax, even when using --py-version, so pylint simply fails to warn.
I'd suggest running pylint on Python 3.11 or older if you want to catch this class of bugs.