Skip to content

Choice of Typechecker #1627

Description

@FallenDeity

Now that we have migrated to uv as choice of package manager and ruff for formatting with #1553 and #1602 the next step is to add a type checker to the project for static type checking. Advantages of static type checking are needless to say easier error detection, code readability/self documenting and much much better ide support.

Now we have a few typecheckers to choose from which include popular battle tested type checkers like mypy, pyright and new ones like ty, zuban, pyrefly. Now out of these few of which have been raised in prior discussions include ty and pyright.

ty being part of astral ecosystem does promise integration with ruff linting rules https://github.com/astral-sh/ruff/issues?q=is%3Aissue%20state%3Aopen%20label%3Atype-inference although ty seems to lag a bit in conformance as of right now in partial/unsupported features they seem to be actively developing targeting 1.0 release this year. Another advantage is ty follows a gradual guarantee adding type annotations to code only narrows existing errors rather than creating new ones although that doesn't mean no errors on untyped code

pyright a popular typechecker and same as the default vscode python extension type checker pylance (which means lsp and typechecker behavior match) it covers pretty much almost all typing cases and has a large community and developers using it over the years. One of the features I am eyeing for this project is part of basepyright' is a fork of pyright (frequently rebases pyright and builds on top of it so not a maintenance concern) and pretty much same conformance and performance as pyright but with some additional developer kitting, of which one I think would be awesome for this
https://docs.basedpyright.com/latest/benefits-over-pyright/baseline/

this creates a baseline of initial type errors in a file which is like an allowlist and we can gradually over multiple prs type/work out the errors in this baseline file without a ton of ignore comments or lumping perhaps missing types from new code along with old ones for future todo

so ci dosent cry about old errors only informs on errors in new/modified code

these two are probably what I would be leaning towards, just a note all of them are mit licensed except zuban which is agpl iirc shouldnt have a problem using it but definitely something to keep in mind

here is a python org released conformance results for each of them: http://htmlpreview.github.io/?https://github.com/twbs/bootstrap/blob/gh-pages/2.3.2/index.html

this is mostly a discussion about which type checker to adopt for this project when each typechecker seems to be opinionated in its own little ways so feel free to share your thoughts regarding this :)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions