chore(pyright): #1171 return None when possible; disable reportUnknownLambdaType

[cmp0xff]

• Addresses Strict report as of 3/13/2025 #1171.
  • reportPrivateUsage 42. Can we disable this forever? Importing _PrivateObjects is widely used in Pandas. We cannot remove them.
  • reportUnknownLambdaType: 50. Can we disable this forever? They are only in tests at places where one can insert a callable.
  • reportUnknownArgumentType: 118.
  • reportUnknownVariableType: 405.
  • reportMissingTypeArgument: 430.
  • reportMissingParameterType: 799.
  • reportUnknownParameterType: 1235.
  • reportUnknownMemberType: 1411.

If one wants to investigate the errors individually, here's the JSON snippet that can be inserted to pyrightconfig-strict.json. Simply enable the specific categories of error of interest.

{
  "reportUnknownArgumentType": false,
  "reportUnknownVariableType": false,
  "reportMissingTypeArgument": false,
  "reportMissingParameterType": false,
  "reportUnknownParameterType": false,
  "reportUnknownMemberType": false
}

[Dr-Irv]

I think we need to keep reportPrivateUsage in there. I think pyright is wrong for reporting them in stub files. Created an issue: microsoft/pyright#10992

From the test files, we will be able to fix this once pandas 3.0 is released, where there will be a pandas.api.typing.aliases which will be the supported way for people to import instead of using pandas._typing. One reason I introduced the aliases was to get around this particular warning.

[cmp0xff]

Added back in 7d3c152

[cmp0xff]

/pyright_strict

[cmp0xff]

• Also added -> None to tests and other possible places
• pyright_strict errors reduced from 3732 to 3682.

[cmp0xff]

Added back in 7d3c152

[Dr-Irv]

thanks @cmp0xff . With respect to the python functions in .py files returning None, is there some test we can include for new PRs (in pre-commit, or in the type checkers) that would pick that up?

[cmp0xff]

is there some test we can include for new PRs (in pre-commit, or in the type checkers) that would pick that up?

Hi @Dr-Irv, I used ANN rules in ruff. I did unsafe-fixes and then checked manually. Maybe we can also introduce a ruff_strict test in the main branch, including more rules?

[Dr-Irv]

Hi @Dr-Irv, I used ANN rules in ruff. I did unsafe-fixes and then checked manually. Maybe we can also introduce a ruff_strict test in the main branch, including more rules?

I'd rather be incremental in adding rules in pyproject.toml for ruff . So if adding ANN works, we can do that, and do it for other rules as well.

[cmp0xff]

We are very far from making all ANN rules work.

Alternatively I can propose that we select "ALL" ruff rules and exclude not working rules, which we gradually fix and remove (or decide not to support)

[Dr-Irv]

Alternatively I can propose that we select "ALL" ruff rules and exclude not working rules, which we gradually fix and remove (or decide not to support)

I'm fine with that. We already exclude some rules already.

My goal in bringing this up is that in this PR, you changed test functions to return None, so we'd want to make sure that in future PRs, this is automatically caught/fixed.