fix: cleanup ruff rules

[alec-bike]

This PR tidies up some ruff rules and comments in pyproject.toml:

• increase max-complexity to 15 (allows removal of some noqa: C901 annotations) reverted
• remove commented-out preview-only ruff rules¹

Also, the experimental tool.pyright section has been simplified (and tested against pyright and basedpyright).

Footnotes

1. ruff preview was turned off in fix: type issues with Chart mark methods. #3936 ↩

[dangotbanned]

@alec-bike there are 2 PRs here

Pyright

Also, the experimental tool.pyright section has been simplified (and tested against pyright and basedpyright).

Could you set up pyright to run in CI first, before making changes like this please?

I was working towards that a while back, but there's nothing verifying your claims.

Locally, pyright is complaining about things that are invisible to a reviewer:

Show arbitrary example

Ruff

I don't see any value in removing C901 comments.

Refactoring the functions is a good way to learn about how altair works or just simplify things for future readers 🙂

[alec-bike]

Thanks for the review @dangotbanned.

Could you set up pyright to run in CI first, before making changes like this please?

I've been wondering about the status of pyright (and multiple type checkers) in altair. Is the goal for altair to support both mypy and pyright in CI?

I've been running ty for my testing, using a local ty.toml config to keep it separate from pyproject.toml. Would altair also want to run ty in CI?

[dangotbanned]

#3967 (comment)

I've been wondering about the status of pyright (and multiple type checkers) in altair. Is the goal for altair to support both mypy and pyright in CI?

I guess this is a history of the progress I made with pyright support:

• https://github.com/vega/altair/pulls?q=sort%3Aupdated-desc+is%3Apr+author%3Adangotbanned+is%3Amerged+typing

Before that, there was a long road to supporting mypy:

• https://github.com/vega/altair/pulls?q=sort%3Aupdated-desc+is%3Apr+mypy+is%3Amerged+author%3Abinste

This section of the config was where there were still gaps, but IIRC some test modules were an issue as well:

altair/pyproject.toml

Lines 374 to 378 in 356c78b

	ignore = [
	"./altair/vegalite/v6/schema/channels.py", # 716 warns
	"./altair/vegalite/v6/schema/mixins.py", # 1001 warns
	"./altair/jupyter/", # Mostly untyped
	"./tests/test_jupyter_chart.py", # Based on untyped module

I've been running ty for my testing, using a local ty.toml config to keep it separate from pyproject.toml. Would altair also want to run ty in CI?

I'm very much looking forward to using ty when it is ready, but there are many gaps that impact an upstream project I contribute to:

• Tracking: Adopt ty as an (additional) type checker narwhals-dev/narwhals#3409

Using ty locally is probably the best move for now - I have no doubt it will play a really important role in moving python forward.

Running pyright in ci is quite doable - with the right amount of effort.
If you look at Python Type System Conformance Test Results - it really is the bar for following the rules 😄
Wish it was faster though

[dangotbanned]

Thanks for the changes @alec-bike

I do still have a few more questions though