Accepted:
Specification https://www.python.org/dev/peps/pep-0634/
Motivation and Rationale https://www.python.org/dev/peps/pep-0635/
Tutorial https://www.python.org/dev/peps/pep-0636/
Rejected:
Unused variable syntax https://www.python.org/dev/peps/pep-0640/
Explicit Pattern Syntax for Structural Pattern Matching https://www.python.org/dev/peps/pep-0642/
https://discuss.python.org/t/gauging-sentiment-on-pattern-ma...
However, I’d say that “accept 634 + another” is clearly opposed to “accept 634 & reject both others”, which is the decision that has been made.
match status:
case 404:
return "Not found"
not_found = 404
match status:
case not_found:
return "Not found"
Edit: It is possible to use constants or variables in a case pattern, but they have to be dotted names to not be treated like a capture pattern. So this would work for your example:
class HttpStatus(Enum):
NOT_FOUND = 404
match status:
case HttpStatus.NOT_FOUND:
return "Not found" def _id(x): return x
not_found = 404
match status:
case _id(not_found):
return "Not found"Couldn't we achieve the same functionality with a little less ambiguity using the following syntax?:
not_found = 404
match status:
case not_found:
return "Not found"
case _ as foo:
do_something(foo)
return "Match anything"
match json_pet:
case {"type": "cat", "name": _ as name, "pattern": _ as pattern}:
return Cat(name, pattern)
case {"type": "dog", "name": _ as name, "breed": _ as breed}:
return Dog(name, breed)
case _:
raise ValueError("Not a suitable pet")