On Wed, 24 Jun 2020 at 11:44, Greg Ewing
Another possibility would to be allow cases to share the same suite by stacking them:
case 401: case 402: case 403: ...
I feel as though this could be useful (although I don't have a specific use case in mind). The obvious alternative would be to define a named function: def handle_40x(): ... case 401: handle_40x() case 402: handle_40x() case 403: handle_40x() But in spite of arguments about naming functions being cheap and good practice, I can still see myself missing the "stacked alternatives" form sometimes. Covering a few other points made in the thread: * I can't see much value in having `else:` - `case _` is a common way of writing a "catch all" pattern in many languages (although certainly "else" is used too) and I'd rather there be a single valid way, to avoid endless debates over style. We can't realistically disallow `case _`, as that's just a consequence of the general rules, so `else` should be the one to drop. * The use of `_` as wildcard feels fine to me (i18n notwithstanding). It's a common convention in Python, and in other languages that have match constructs. * The .VALUE syntax makes me sad, although I don't have a particularly good alternative to suggest. I'd certainly be able to learn to live with it, though. * Putting the expression on a line below the match keyword feels less natural to me than the current proposal. I don't have a particular logic or analogy for that (arguments about "it's like try...except" don't feel compelling to me), I just prefer the syntax in the PEP. Paul