On Wed, 24 Jun 2020 at 11:44, Greg Ewing <[email protected]> wrote:
> 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
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/AE2IXYYHIXNMJYYD4LH5TEPG577367UA/
Code of Conduct: http://python.org/psf/codeofconduct/
