pyre-check VS pyright

Internally we use Pyre for Python type checking: https://github.com/facebook/pyre-check

Before type hinting, work had intense rules and linters enforcing docstrings with types. Now, type hints and automatic pyre runs take care of all the heavy lifting.

Python now has an optional type system and if you add one of them such as mypy or pyre to your CI process and you can configure GitHub to refuse the pull request until types are added you can make it somewhat strongly typed.

If you have a preexisting codebase I believe the way you can convert it is to add the types that you know on commits and eventually you will have enough types that adding the missing ones should be easy. For the missing ones Any is a good choice.

https://pyre-check.org and https://github.com/python/mypy are popular.

So to find things in a similar space, you need to look for languages with these sorts of constraints - so things like Sorbet for Ruby or pyright/pyre and you'll see similar and new ideas

Facebook/Instagram uses Pyre which is a typechecker for Python.

I'd be curious if the pyre-check compilation is any faster for you either by removing the inlining optimization flag (the `-Oclassic` here https://github.com/facebook/pyre-check/blame/36243764ab81a82...) or whether there's a way to compile pyre-check to bytecode instead of the native compilation step (which unfortunately it looks like there's no easy way to modify pyre-check's build config to do so).

I must be doing something wrong.

[1] https://github.com/facebook/pyre-check

Some other good alternatives for type checking are Pyright (which is seen in VSCode via Microsofts PyLance plugin) and Pyre.

Function annotations were added as part of Python 3.0, with PEP 3107, proposed in 2006 [0]. The first public mypy commit was in 2012 [1], and originally it was using C++-style syntax (`list lex(str s):`). The `typing` module and the official use of function annotation for type hints came in 2014 with PEP 484 [2], inspired by mypy. The first pyright commit was in 2019 (with a lot of code in the third commit [3], possibly moved from the VSCode extension).

[0] https://peps.python.org/pep-3107/

[1] https://github.com/python/mypy/commit/6f0826a9c169c4f05bb893...

[2] https://peps.python.org/pep-0484/

[3] https://github.com/microsoft/pyright/commit/1d91744b1f268fd0...

This is not the case! After reading the LSP help pages (:help lsp), I installed and configured two language servers: Typescript Language Server for JavaScript and Pyright for Python. Neovim has fantastic defaults, so things like tags, omnicompletion, and semantic highlighting (New in 0.9) are enabled and configured by default as long as your language server supports them. You can see my configuration below.

pyright the language server does not (and probably will not) support inlay hints: https://github.com/microsoft/pyright/issues/4325

Are you using pyright for LSP? I currently use pipenv instead of conda, but I configure the venv and venvPath fields in a pyrightconfig.json file (docs here) in the project root. This way, pyright picks up on the right environment automatically when I open Neovim.