Support linting entrypoints that don't end in .py

[btalb]

There's been a number of issues (e.g. #3398, #3163) with minor use cases for why the current "no .pyi? extension = not a Python file" behaviour is frustrating.

I'd like to instead focus the discussion on an established, widespread, use-case: Unix shebangs . Python's even monkey-patched support into the launcher so they can be used on Windows. There's lots of discourse on whether executables with shebangs and file extensions make sense, with lots of standard tools seemingly on the no side. For example, this returns 218 results on my machine:

find /usr/ -not -name '*.py' -type f -executable -exec awk '/^#!.*python/{print FILENAME} {nextfile}' {} + | wc -l

What adds to the confusion is my editor happily lints these with Pyright (presumably because it's determined the file type, then passed the raw text to the running language server). If it can be done in the editor, it would be nice if that was consistent with what I can do via the cli.

Personally, I feel decisions like this shouldn't be made authoritatively by a linter. Let the user decide what they want to pass to the linter, and they can suffer the consequences of "rubbish in equals rubbish out". If there's a way it could be valid Python usage, please let us pass it in.

note: the limiting to .pyi? files makes perfect sense for things that are imported, that's a detail of how Python works, I'm just talking about the entrypoints here for a command like pyright --verbose my_shebang_python_file_with_no_extension

Possible solutions

There's a number:

• disable the check entirely
• expose the regex as a config parameter users can change
• add a more controlled flag that allows users to explicitly say "yes I want things without the extension"
• expand the basic regex check to be a "filename has this regex or is an executable with a Python shebang"

Personal preference would be for either of the last two. Hopefully something there can both align with the design goals of the project, and support linting of well-established Python usage practices.

Tip for those needing to get around this for now

1. npm install pyright as normal
2. run the following to disable the "no .pyi? extension = not a Python file" regex from here:

   sed -i 's|/\\\.pyi?$/|/./|g' $(dirname "$(realpath $(which pyright))")/dist/pyright-internal.js
   

[erictraut]

Thanks, I think you've made a compelling argument for removing this limitation. I don't think it was even added intentionally — at least not for the CLI. It was added in a code path that is used for the include config option, and it was added as a sanity check for that config value. I've removed the check so the CLI can now be used on files that don't end in ".pyi?". This will be included in the next release.

[btalb]

Nice. Thanks a lot for getting onto that so quickly @erictraut !

[erictraut]

This is included in pyright 1.1.317, which I just published.