Add pyrefly type checking.

[AndreasBackx]

This adds pyrefly to the type checking. I'm working on a lot of typing improvements and it's helpful to have a third one because it's sometimes not really clear why pyright is saying typing is wrong. It already is saying some things are incorrect which I'm planning to look into.

I hope it's not going to lead to a conflict of typing issues, and if so, we can review this more closely in the future.

As of writing I've not fixed the typing issues, but I'll publish the PR once done.

[kdeldycke]

Typing is not my forte. In my projects I just fire up a mypy and try to make it happy. Waiting for ty to mature a bit and I'll switch to it in the future.

So I'll let other give feedback on that topic and I'll just follow the movement! 😁

[davidism]

I'd prefer to stick to mypy for now. If we're still testing with pyright, we can remove that; it was added when I thought we needed to test with all of them. But really, we just need to test with mypy for our own code, and pyright --verifytypes to know that we export complete types for others to use in their code.

I know pyrefly is working on an export verifcation as well, but I tried last month and both its type checking and verifcation weren't ready yet. Same with ty. I'm really interested in those two, but prefer we wait for now. mypy, for all its quirks, is very mature and actively maintained.

[davidism]

Regarding static typing in general, remember: annotations are there to serve us and our users, not the other way around. Click (and all of Pallets) predates static typing, and we would design it differently today to be better typed. So if we're doing something weird and typing can't express it (or it's too complicated to figure out), you're fine adding # type: ignore[error code] comments to insist that a return type is what we say it is, that a use of an argument is correct, etc.

[AndreasBackx]

Wasn't expecting the comments just yet. 😅 I was primarily using this to experiment a bit on where we could improve typing. It's very neat to see where we could make the typing experience Click offers better, and also make it less of a pain to use inside of the codebase. So far it's teaching and frustrating me, as I'm expecting certain typing to be possible (as someone who uses Rust quite a bit) and then it seems to not be possible.

My current struggle is trying to plug through the binary/text file modes without having to repeat if "b" in mode everywhere and casting. There's fairly little that I can find on this and how others solve it.

I'll see where my experimentation gets me. But I'm not expecting all that much just yet.

So far Pyrefly is easier to use than pyright:

1. No waiting multiple seconds to type check the codebase.
2. Actually readable output from the CLI.

And mypy seems to sometimes not be as strict as pyright nor pyrefly, I've found it to be useful to see what the different ones say.

Regardless of where the typing experimentation goes, I do think it'd be useful to have multiple type checkers available. It sometimes helps to see how each one of them views a problem, even when we only care about a single one (mypy). Would we be able to have pyrefly and ty added and available via uvx pyrefly/ty which would make this easier (but not enabled in CI/tox)?

[davidism]

Yeah it's fine to add config for it and use it to figure things out, just don't want to require it in CI yet.

[Rowlando13]

I am interested to see where this goes. I switched to pyrefly mostly because the Language server works better in vscode.