Rule request
Thesis
We should support simplifying match statements that use simple sequence and mapping patterns:
Example:
match data:
case [1, 2]:
handle_pair()
case _:
ignore()Can be rewritten as:
if data == [1, 2]:
handle_pair()
else:
ignore()Reasoning
Using match for exact structural comparisons of simple literals is unnecessarily verbose. While match excels at deconstruction, using it to check for an exact list or dict value is better expressed with a direct equality comparison (==), which is more readable and performant.
These patterns are common in configuration checks, API responses, and state validation.
When should this be allowed?
Only when:
- There are exactly two cases (with
case _:)
- The first pattern is a simple sequence like
[1, "a"] or a simple mapping like {"x": 1}
- All elements/keys/values are simple (literals, constants, names)
- No starred patterns (
*rest) or variable bindings (case [x, y]:)
- Keys in mappings are constants (not variables)
Not allowed if:
- Uses deconstruction (e.g.
case [x, y]:)
- Contains
*args or **kwargs
- Has guards (
if ...)
Rule request
Thesis
We should support simplifying
matchstatements that use simple sequence and mapping patterns:Example:
Can be rewritten as:
Reasoning
Using match for exact structural comparisons of simple literals is unnecessarily verbose. While match excels at deconstruction, using it to check for an exact list or dict value is better expressed with a direct equality comparison (
==), which is more readable and performant.These patterns are common in configuration checks, API responses, and state validation.
When should this be allowed?
Only when:
case _:)[1, "a"]or a simple mapping like{"x": 1}*rest) or variable bindings (case [x, y]:)Not allowed if:
case [x, y]:)*argsor **kwargsif...)