I don't see the link between that output and your conclusion. Are those results wrong?

> Are those results wrong?

I don't know. Some packages just don't work with type checkers, e.g. Django.

Django has a community stubs project, are you using it?

Does django-stubs work with other type checkers than Pyright?

Stubs are a standard python feature (PEP 561) so I'd expect them to work with any type checker which supports stubs, which should be all of them (as much of the ecosystem is typed via stubs).

the stubs can only do so much. There's so much magic and inferred properties that a type checker will never be able to fill in alone

Is it not that he used the "--suppress-errors" flag yet it did not ignore the errors?

It's hard to tell. Other similar options in other commands can mean things like "exit with status 0 even if errors are detected". Without installing pyrefly, I'm not sure what that flag's supposed to do. It's not documented on their site.

It adds a comment to suppress the error above each line in your codebase that causes an error, but it reports the errors before doing that, so you can only see the result after you re-run `pyrefly check`.

Oh! That's nifty. It leaves you with a baseline so you can stop making new mistakes, and gives you something to grep for when you want to fix existing ones.

Thanks for giving this a try! We go over how to use the upgrade tooling (`--suppress-errors`) in the guide here: https://pyrefly.org/en/docs/installation/. This is intended to make upgrading from different versions of type checkers easier. It’s something we use internally and wanted to share with the community along with the checker itself.

We also allow you the ability to suppress whole classes of errors if you want to ignore specific error types and avoid inline ignores: https://pyrefly.org/en/docs/configuration/ A word of caution: this will ignore future errors of this type as well.

First, make sure your project is properly configured and then follow the instructions. `--suppress-errors` will add ignores inline allowing the project to check cleanly. We have thought about a feature that allows you to keep suppressions in a separate file, but we have not put it on the roadmap yet. If this is something important for your workflow, we would like to learn more - please add a feature request on GitHub.

It's literally working? What did you expect?

Maybe it's working but it's not useful.

What would you expect "useful" to be if your codebase is basically incompatible with type checking?

I expected that I would be able to run the check command and it would just work. Upon reading the docs, this tool recommends incremental adoption, and after using `--suppress-errors`, `# pyrefly: ignore` is all over my codebase.

I know I shouldn't get into this thread, but I'm extremely curious: what did you expect should have happened? I mean, literally, what do you mean by "just work", what work did you expect a type checker to perform if not to show you errors?

I expected a reasonable amount of reasonable errors, not 60k+ errors most of which are import-error, even though the code runs fine.

edit: most errors weren't actually import-error, I just misunderstood --search-path

Its the fault of the tool that the codebase had lots of errors?

I would say it's the fault of the ecosystem. Hopefully it will get better as libraries adopt type hints.

That's incremental adoption for adding type hints, not for adopting this particular tool in an already-type-hinted codebase.

…how else would it work?

Fix your types.

Don't blame the tool for your shoddy work. Either accept your mediocre quality or do something to fix it.

Do you... have type annotations? I think you might be missing the point.

I think the point here is that for something like Python the default behaviour should be an assumed return type of `Any` rather than throwing an error. Maybe that is the case and the GP had configured it otherwise.

No it shouldn't because then you can easily miss places where you should have added a type annotation, and also your lazy colleagues won't bother adding them at all.

The worst of both worlds is colleagues who insert type annotations but they're wrong. And there's no CI pipe to verify the types before check-in.

Working with these things makes me often think that people who want to write high quality software should just use a better language. But, well, real world is real.

> just use a better language

This

Yeah unfortunately Python is crazy popular so a lot of the time you don't get a choice.

If fairness if you set up uv and Ruff and Pyright it's kind of ok. Still have to deal with the general noobness of the ecosystem and the horrific performance, but I've seen worse.