Use this command with a shell that supports process substitution (e.g. Bash): mypy <(cat).
For example:
echo "1 + 'a'" | mypy <(cat)
This will redirect text input from stdin (standard input) to mypy for type checking.
mypy should behave exactly the same way as when it is passed a filename, so you can pass any other flags.
sh-5.2$ echo '1 + "a"' | mypy --strict <(cat)
dev/fd/63:1: error: Unsupported operand types for + ("int" and "str") [operator]
Found 1 error in 1 file (checked 1 source file)
Any other flags can be passed to mypy:
sh-5.2$ echo 'print(a)' | mypy --strict <(cat)
dev/fd/63:1: error: Name "a" is not defined [name-defined]
Found 1 error in 1 file (checked 1 source file)
If the feature detailed in this GitHub issue is added to mypy, then the future solution will work on more POSIX compliant shells and it will be similar to other software. Unfortunately, mypy - does not work as of May 2023.
Processing stdin adds more flexibility to a UNIX command, and allows for use of other functionality, such as piping input from another process into mypy or using it in non-standard environments.
Read a bit about the Unix philosophy in Matt Might’s article.
We’re using it to write a linting/fixing plugin for the Vis editor, called vis-lint.
By directing stdin into mypy and other linters/code quality tools, we can avoid creating temporary files and other nice features.
For code fixing tools that would modify your files, it as though they are taking over the keyboard and fixing the code for you when you pipe the editor’s contents directly into the program.
It also allows us to keep supporting Vis’ powerful feature of interactive editing of stdin, since this editor supports input from stdin and output to stdout: