4 ms·

I'm very impressed by the recent developer experience improvements in the python ecosystem. Between ruff, uv, and https://github.com/gauge-sh/tach https://githu

I'm very impressed by the recent developer experience improvements in the python ecosystem. Between ruff, uv, and https://github.com/gauge-sh/tach https://github.com/gauge-sh/tach we'll be able to keep our django monolith going for a long time. Any opinions about the current state of the art type checker?

tylerhillery 2y ago
I have always used MyPy but I have noticed some large open source projects adopt Pyright as of late. The folks behind ruff and uv are currently working on a type checker as well but haven't heard when they plan on releasing it.
- ubercore 2y ago
  MyPy is nice, but it has missed some things that pyright caught, which were legitimate bugs that could have arisen.
- claytonjy 2y ago
  has Astral confirmed they’re doing a type checker? i’m not surprised, everyone has been asking for it, but i haven’t seen them say they’re doing it
  - tylerhillery 2y ago
    Yes it's confirmed, you can listen to Charlie talk about here: https://youtu.be/byynvdS_7ac?si=JWeeD3uwXflWl5jo&t=1980 https://youtu.be/byynvdS_7ac?si=JWeeD3uwXflWl5jo&t=1980 Code Name is Red Knot: https://github.com/astral-sh/ruff/discussions/12143 https://github.com/astral-sh/ruff/discussions/12143
Mehdi2277 2y ago
I'm very happy with pyright. Most bug reports are fixed within a week and new peps/features are added very rapidly usually before pep is accepted (under experimental flag). Enough that I ended up dropping pylint and consider pyright enough for lint purposes as well. The most valuable lints for my work require good multi-file/semantic analysis and pylint had various false positives. Main tradeoff is this only works if your codebase/core dependencies are typed. For a while that was not true and we used pylint + pyright. Eventually most of our code is typed and we added type stubs for our main untyped dependencies. edit: Also on pylint, it did work well mostly. tensorflow was main library that created most false positives. Other thing I found awkward was occasionally pylint produces non-deterministic lints on my codebase.
catlover76 2y ago
Pyright is pretty good. It's easy to setup, and has first-class VSCode support, if that's what your team uses.
optionalsquid 2y ago
Everyone is already recommending pyright, but I'll suggest checking the "based" community fork: https://github.com/detachhead/basedpyright https://github.com/detachhead/basedpyright Besides re-adding features that Microsoft makes exclusive to pylance, it tweaks a number of features that IMO makes pyright work better out the box: https://docs.basedpyright.com/latest/benefits-over-pyright/pylance-features/ https://docs.basedpyright.com/latest/benefits-over-pyright/p...
- orra 2y ago
  Thanks for linking this. I wasn't surprised Microsoft made their AI auto completion proprietary (they did similar for C# in VSCode). But it grated me that semantic highlighting wasn't open source.
  - neonsunset 2y ago
    What did they do for C#?
    - dagw 2y ago
      They added some closed source features to the C# developer extension in VSCode. So anybody using a non-Microsoft fork of VSCode can't use those features.
      - neonsunset 2y ago
        If you are referring to the debugger, they did not "add" it - it was like that from the start. The C# extension is MIT, but the 'vsdbg' it ships with isn't because it's a debugger Visual Studio uses made into a standalone cross-platform component. You can use an extension fork which swaps it with NetCoreDbg maintained by Samsung instead. This is what VSCodium uses. Also note that both of these essentially consume the debugger API exposed by the runtime itself, you can easily make one yourself in a weekend but no one bothered because there isn't much need for another one.
ducdetronquito 2y ago
First thanks for mentioning tach, I wished this tool existed for a long time and I'm happy to give in a try in the following days! For typechecker, I also vouch for Pyright which is what we use for all our django backends at work. Just be aware that you will have hard time to typecheck part of your code where you rely heavily on django's magic (magic strings, auto-generated properties/methods, etc...). In these cases, it's sometimes better to avoid these features entirely or accept that some part of your code will not be typechecked.
- rikthevik 2y ago
  I haven't dug into tach yet, but I'm very optimistic on this one.

tylerhillery 2y ago

I have always used MyPy but I have noticed some large open source projects adopt Pyright as of late. The folks behind ruff and uv are currently working on a type checker as well but haven't heard when they plan on releasing it.

ubercore 2y ago
MyPy is nice, but it has missed some things that pyright caught, which were legitimate bugs that could have arisen.
claytonjy 2y ago
has Astral confirmed they’re doing a type checker? i’m not surprised, everyone has been asking for it, but i haven’t seen them say they’re doing it
- tylerhillery 2y ago
  Yes it's confirmed, you can listen to Charlie talk about here: https://youtu.be/byynvdS_7ac?si=JWeeD3uwXflWl5jo&t=1980 https://youtu.be/byynvdS_7ac?si=JWeeD3uwXflWl5jo&t=1980 Code Name is Red Knot: https://github.com/astral-sh/ruff/discussions/12143 https://github.com/astral-sh/ruff/discussions/12143

Mehdi2277 2y ago

I'm very happy with pyright. Most bug reports are fixed within a week and new peps/features are added very rapidly usually before pep is accepted (under experimental flag). Enough that I ended up dropping pylint and consider pyright enough for lint purposes as well. The most valuable lints for my work require good multi-file/semantic analysis and pylint had various false positives. Main tradeoff is this only works if your codebase/core dependencies are typed. For a while that was not true and we used pylint + pyright. Eventually most of our code is typed and we added type stubs for our main untyped dependencies. edit: Also on pylint, it did work well mostly. tensorflow was main library that created most false positives. Other thing I found awkward was occasionally pylint produces non-deterministic lints on my codebase.

catlover76 2y ago

Pyright is pretty good. It's easy to setup, and has first-class VSCode support, if that's what your team uses.

optionalsquid 2y ago

Everyone is already recommending pyright, but I'll suggest checking the "based" community fork: https://github.com/detachhead/basedpyright https://github.com/detachhead/basedpyright Besides re-adding features that Microsoft makes exclusive to pylance, it tweaks a number of features that IMO makes pyright work better out the box: https://docs.basedpyright.com/latest/benefits-over-pyright/pylance-features/ https://docs.basedpyright.com/latest/benefits-over-pyright/p...

orra 2y ago
Thanks for linking this. I wasn't surprised Microsoft made their AI auto completion proprietary (they did similar for C# in VSCode). But it grated me that semantic highlighting wasn't open source.
- neonsunset 2y ago
  What did they do for C#?
  - dagw 2y ago
    They added some closed source features to the C# developer extension in VSCode. So anybody using a non-Microsoft fork of VSCode can't use those features.
    - neonsunset 2y ago
      If you are referring to the debugger, they did not "add" it - it was like that from the start. The C# extension is MIT, but the 'vsdbg' it ships with isn't because it's a debugger Visual Studio uses made into a standalone cross-platform component. You can use an extension fork which swaps it with NetCoreDbg maintained by Samsung instead. This is what VSCodium uses. Also note that both of these essentially consume the debugger API exposed by the runtime itself, you can easily make one yourself in a weekend but no one bothered because there isn't much need for another one.

ducdetronquito 2y ago

First thanks for mentioning tach, I wished this tool existed for a long time and I'm happy to give in a try in the following days! For typechecker, I also vouch for Pyright which is what we use for all our django backends at work. Just be aware that you will have hard time to typecheck part of your code where you rely heavily on django's magic (magic strings, auto-generated properties/methods, etc...). In these cases, it's sometimes better to avoid these features entirely or accept that some part of your code will not be typechecked.

rikthevik 2y ago
I haven't dug into tach yet, but I'm very optimistic on this one.