refactor: ♻️ revise post to decide on Pyrefly, not mypy#313
Conversation
signekb
left a comment
signekb
left a comment
There was a problem hiding this comment.
Interesting. Looking forward to trying it out.
| Facebook. Additionally, we continue to use VS Code's Pylance language server, | ||
| which runs Pyright internally, complementing the feedback we get from `mypy`. | ||
| We decided on Pyrefly as it recently made an official stable release, and | ||
| compared to `mypy` is just so much faster. It has all the necessary features we |
There was a problem hiding this comment.
| compared to `mypy` is just so much faster. It has all the necessary features we | |
| compared to `mypy`, it is just so much faster. It has all the necessary features we |
| Static type checking helps to catch bugs earlier and contributes to the long-term maintainability and overall quality of Python codebases. | ||
| This post explains why we chose `mypy` as our static type checker over other alternatives. | ||
| Static type checking helps to catch bugs earlier and contributes to the | ||
| long-term maintainability and overall quality of Python codebases. This post |
There was a problem hiding this comment.
| long-term maintainability and overall quality of Python codebases. This post | |
| long-term maintainability and overall quality of Python codebases. This post |
github-project-automation
Bot
moved this from In review
to In progress
in Platform development
joelostblom
left a comment
joelostblom
left a comment
There was a problem hiding this comment.
I'll approve in terms of the edits to the post, but I have a higher level question about the decision to switch type checker at this point: Are we expecting to switch ty at some point later when there is a stable release? I'm thinking that would be closely integrated to that we already use uv and ruff from astral and I don't see any strong reason here against it other than the lack of a stable release.
If we are planning to switch (or even consider switching to ty) in the not too distant future, it could save us time to hold off with implementing this decision so that we don't spend time on swtiching twice: first re-structuring our pipelines and code to work well with how pyrefly does type checking and then again when switching to ty. It seems like there could end up being a lot of time spent on changing tooling between different options otherwise.
If we plan to stick to pyrefly and not consider ty, then I see no issue.
3 participants
Description
Pyrefly had its first stable release, so this is a good time to switch now.
Needs a quick review.
Checklist
just run-all