Caveats:
- Any expression (unless you allow reference to variables previously bound by the match statement) can just be aliased (as long as you don’t need short circuiting), so it’s not a critical feature. Constant value patterns are the most easily replaceable by if/elif part of PEP 622.
- I’m sure the PEP authors have a better understanding than I of what use cases come up in practice; the fact that they didn’t address this is maybe revealing.
- A discussion of allowing expressions in constant value patterns is a slight digression from alternative syntax for constant value patterns and I don’t want to go too deep down the rabbit hole and lose sight of the original question.
I think it could be very reasonable to want to use dictionary lookups, especially since a lot of older code / libraries use dicts for enum-like use cases.
And arithmetic expressions (outside of powers of 2 and 10):
```
match unit_value:
case %(7 * 24 * 60 * 60): return “week”
...
```
And function calls:
```
match hsv_color:
case %(hsv(“black”)): ...
case %(hsv(“cyan”)): ...
case (_, 0, _): return “some sort of grey”
match git_bisect_action:
case %(config.get_old_term()): ...
case %(config.get_new_term()): ...
match conn:
case %(get_current_conn()): ...
case Connection(host, port): ...
```
The caveats above apply, and even if you find the above examples compelling, this would probably fall in the 10 bucket of 90/10 usage. But if our syntax for constant value patterns made it natural / easy to support, it’s something to consider, either now or later a la PEP 614.