TYP: add mypy defaults to pyproject.toml
may make it easier for contributors to experiment with enabling mypy strictness flags
When we did check_untyped_defs we created an exclude list.

IIRC it takes some maintenance to have an exclude list with more than one flag as IIRC later configs override earlier ones.

Since none of the remaining flags are as important (except maybe the imports resolving to Any now that we have stubs for the cython code) as check_untyped_defs, we have not yet enabled any other flags.

We probably also still have a few "fix later" ignores from enabling check_untyped_defs globally to deal with.

for the untyped decorators, if #43744 solves the @cache_readonly issue, then probably only numba stubs for the numba.jit decorator is needed on that one.

In the past we also discussed using the module level comment syntax to make mypy checking more strict, but IIRC there was preference to keep all mypy config in the global config file.

So if that is still the case, I find implementing a level system like https://github.com/numba/numba/pull/6222/files an interesting alternative. How would something like that fit with pyright type checking. > In the past we also discussed using the module level comment syntax to make mypy checking more strict, but IIRC there was preference to keep all mypy config in the global config file.

Pyright supports comments in files https://github.com/microsoft/pyright/blob/main/docs/comments.md

> So if that is still the case, I find implementing a level system like https://github.com/numba/numba/pull/6222/files an interesting alternative. How would something like that fit with pyright type checking.

I don't think pyright supports this https://github.com/microsoft/pyright/issues/953

If we enable decorator checking in both mypy and pyright, we could use ignore statements for the numba functions. > > In the past we also discussed using the module level comment syntax to make mypy checking more strict, but IIRC there was preference to keep all mypy config in the global config file.
> 
> Pyright supports comments in files https://github.com/microsoft/pyright/blob/main/docs/comments.md

The ability in pyright to add `# pyright: strict` and then exclude some checks with say `# pyright: strict, reportPrivateUsage=false` at first glance seems to be easier to maintain and grok than the equivalent mypy syntax of enabling individual checks

In light of this, and it would be good to start to lock down some strictness, I would be happy to see comments added to modules for pyright now that we have pyright checking on CI.