RUF031: Ignore unparenthesized tuples in subscripts when the subscript is obviously a type annotation or type alias

[AlexWaygood]

Summary

Fixes #12758. Previously with the setting lint.ruff.parenthesize-tuple-in-subscript = true, RUF031 would have complained about annotations such as dict[str, int], telling you that you should spell them as dict[(str, int)] instead. That feels somewhat silly -- although it is of course a subscription in exactly the same way as a dictionary key lookup, it's not really what the rule is trying to detect.

This PR fixes most of those cases. Unfortunately it doesn't fix cases like this, where it's ambiguous whether the variable is a type alias or not:

import typing
X = typing.Callable[[str, int], bool]  # RUF031 here

Faced with this, however, users have a fairly simple workaround: make it explicit that it's a type alias, and the false positive will go away

import typing
X: typing.TypeAlias = typing.Callable[[str, int], bool]

Test Plan

cargo test -p ruff_linter --lib

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

ℹ️ ecosystem check detected linter changes. (+0 -1 violations, +0 -0 fixes in 1 projects; 53 projects unchanged)

RasaHQ/rasa (+0 -1 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --output-format concise --preview

- tests/utils/test_train_utils.py:117:67: RUF031 [*] Avoid parentheses for tuples in subscripts.

Changes by rule (1 rules affected)

code	total	+ violation	- violation	+ fix	- fix
RUF031	1	0	1	0	0

[AlexWaygood]

RasaHQ/rasa (+0 -1 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --output-format concise --preview

• tests/utils/test_train_utils.py:117:67: RUF031 [*] Avoid parentheses for tuples in subscripts.

Oh, that's ugly. It sorta feels like a shame that we'll no longer be emitting a diagnostic there 😆

I suppose we could only ignore the rule for type annotations/aliases if lint.ruff.parenthesize-tuple-in-subscript = true, and continue to apply the rule everywhere if lint.ruff.parenthesize-tuple-in-subscript = false? But that feels conceptually harder to explain

[dylwil3]

Does it make sense to say in the docstring for the rule that we skip annotations, or is that too in the weeds?

[AlexWaygood]

That's a good idea. I'll add some more docs tomorrow (it's late now where I am :-)

[dylwil3]

Should we also do semantic.in_simple_string_type_definition() here?

[AlexWaygood]

It's not needed -- if the SIMPLE_STRING_TYPE_DEFINITION flag has been set on the semantic model, the TYPE_DEFINITION flag will also have been set:

ruff/crates/ruff_linter/src/checkers/ast/mod.rs

Lines 2196 to 2204 in c4e6519

	let type_definition_flag = match kind {
	AnnotationKind::Simple => SemanticModelFlags::SIMPLE_STRING_TYPE_DEFINITION,
	AnnotationKind::Complex => {
	SemanticModelFlags::COMPLEX_STRING_TYPE_DEFINITION
	}
	};
	self.semantic.flags |=
	SemanticModelFlags::TYPE_DEFINITION | type_definition_flag;

[dhruvmanila]

I think it might make sense to cover generics as well (#12773 (comment)) like:

class Foo(Generic[T1, T2]):
	...

(It can be done as a follow-up.)

[MichaReiser]

such as dict[str, int], telling you that you should spell them as dict[(str, int)] instead. That feels somewhat silly -- although it is of course a subscription in exactly the same way as a dictionary key lookup, it's not really what the rule is trying to detect.

I find it hard to following this reasoning but it's probably just me not writing enough python. Isn't this as "silly" as doing the same in regular subscripts?

[AlexWaygood]

I find it hard to following this reasoning but it's probably just me not writing enough python. Isn't this as "silly" as doing the same in regular subscripts?

Type annotations just have their own specific conventions around them. And the subscription has a very different meaning in a typing context. You're not "looking up" a value at an index or key in a typing context in the same way; and I think the vast majority of people aren't even aware that they're creating implicit tuples in a type annotation context.