Apply ruff preview rule RUF022

[DimitriPapadopoulos]

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[dstansby]

As a general question, why for some of these linting PRs are the rules enabled, and why do some of them have code changes without the rules being enabled? Most of the the changes seem sensible, but won't we have to keep manually fixing if we don't enable the rules to be run by pre-commit?

[DimitriPapadopoulos]

In this case, this is a preview rule. I am merely applying it, knowing the change could be reverted before the rule is adopted.

[DimitriPapadopoulos]

In other cases, I find large parts of a set of rules questionable. I am still trying to evaluate which rules should be enabled or disabled in such sets. In the meantime, I only apply the rules that look OK to me.

[dstansby]

Hmm, I think in terms of keeping maintenance simple it's worth keeping these changes to non-preview rules. But I don't want to block other maintainers if they think these are worthwhile :)

[jhamman]

Hmm, I think in terms of keeping maintenance simple it's worth keeping these changes to non-preview rules. But I don't want to block other maintainers if they think these are worthwhile :)

I'll echo this. Its also fine to apply code quality changes that go beyond ruff rules (thank for the work on this by the way), but perhaps we batch them together a bit more.

My request:

1. Where possible, let's accompany code changes with a non-preview rule
2. If there are changes you want to put forward that are outside of this, let's batch them together into a bit larger PRs or leave them for later.