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 :)
Now that we have migrated to
uvas choice of package manager andrufffor 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
tyandpyright.tybeing part of astral ecosystem does promise integration withrufflinting rules https://github.com/astral-sh/ruff/issues?q=is%3Aissue%20state%3Aopen%20label%3Atype-inference althoughtyseems 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 istyfollows 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 codepyrighta 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 ofbasepyright' 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 thishttps://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 :)