consider ty as alternative to Pyright

[bmerkle]

I had a look at the regressions of Pyright (1.1.406 vs. 1.1.407).
There are really a number of them ( > 10) and it seem they will not be fixed so fast (some of them a open for several month)

Meanwhile there seem to be a good alternative solution with ty (from astral.sh) so we should consider ty as alternative to Pyright
As the docs show https://docs.astral.sh/ty/ the ty Pshon type checker is really fast and it seems to be stricter in checking.
I gave it a try on the current codebase and it found several inconsistencies i am currently checking at...
The ty implementation is still in early stages (0.6 or 0.7) but IMO we should give it a try.
Astral is also the creator of uv and Ruff and they are known for fast and correct implementation.

Proposal:

• Open a PR with ty setup and test the typechecker in comparison to Pyright
• review the results ty reports

docs are here https://docs.astral.sh/ty/

this issue is somewhat similar to #116 where we look at the astral ruff code formatter.

[gvanrossum]

I know the creators of Ty personal and I believe it's too soon to adopt it. I also like the close match between what I see in VS code and what pyright gives me.

I am confident that the regression in pyright will be fixed. And the previous version is just fine.

[bmerkle]

Okay, here are some first findings, maybe we should discuss it briefly via discord...

• pyright currently runs with default setting "typeCheckingMode": "basic" which seems okay.
  I tried it also with strict mode, but then i got tons of messages. Maybe it needs some tweaking.
  I have the feeling that we might miss some type errors and you also mentioned this several times.

• so i gave ty a short try. Running with default settings i found 136 additional messages (warnings and errors).
  I checked a few of them and they seem valid, so we might miss some errors currently.
  I would have a look though the rest of the list and see if they are

1. false positives: --> report them to ty
2. valid messages --> fix in our codebase
   Appended is also a small example and a screenshot

• it does not mean that we switch to ty, but if it reveals additional findings, we should enable them also in pyright (via additional config, so we are sure to catch them)

• I also checked usage of ty versus pyright and they seem to be already on kind of same support regarding command line and VSCode plugin. I am not sure how good the lint findings are of both but cmd and VSCode support are ok.

[gvanrossum]

I still really don't feel like using Ty. There's something about Astral's business model (or lack thereof?) that worries me, and I believe it's not mature/stable enough. I basically don't want to have to change any code because Ty interprets the typing standard differently. There was a long discussion at the typing summit at the last PyCon about that and they seemed pretty strongly opinionated that their way was better. I still don't agree.

But... We can make pyright stricter. I added this to pyproject.toml:

[tool.pyright]
reportUnusedImport = "warning"

and it reported 177 warnings. Add reportUnusedVariables = "warning" and you get 23 more warnings.

How about we fix all those warnings and then we turn on those flags? After that we can tighten the rules more to also require that all variables and parameters have a known type. (See https://microsoft.github.io/pyright/?utm_source=chatgpt.com#/configuration?id=diagnostic-settings-defaults for an overview of all flags and which are already on in standard mode -- which is the default, not basic.)

[gvanrossum]

I am finally at the beach and have a little more time. :-) I am going to try to see if Claude can fix all those for me.

[bmerkle]

yup, makes sense. Thanks for the background information. I was not at PyCon (US) and did not know about those details.
it is not a good sign to interpret standard differently.
I thought there is a official conformance test for typing so do they deviate from that also ?

should i attach the ty findings here so that we can cross check them with the pyright findings ?
( we do not continue the ty path of course then, because of the above reasons)

[gvanrossum]

I'd rather not post a list with hundreds of items here. I am halfway through with fixing unused vars (there's some ambiguity in tests where what seems like a side-effect-free call must be made as it's part of the test :-) ).

Let me see how quick I can turn this into a working PR. Then I'll add the unused imports (should be easier). Then we can run Ty again.

[gvanrossum]

See #129.

I'm not sure when I can merge this: I need an approval of a coworker, and they're on vacation (like me). But you can base your changes on this.

[gvanrossum]

Shall I also try to fix the 177 unused imports? Those should go faster.

[bmerkle]

i can pull #129 into my branch, no problem :-)

[gvanrossum]

#129 was merged. Go ahead and try Ty now.

[gvanrossum]

@bmerkle Do we still need to experiment with ty? I expect not, now that I've added some new configs to pyright. Closing. But if you still want to work on this, let me know and I'll gladly reopen.