On 06/24/2020 01:49 PM, Tim Peters wrote:
I too thought "why not else:?" at first. But "case _:" covers it in the one obvious way after grasping how general wildcard matches are.
"case _:" is easy to miss -- I missed it several times reading through the PEP.
Introducing "else:" too would be adding a wart (redundancy) just to stop shallow-first-impression whining.
Huh. I would consider "case _:" to be the wart, especially since "case default:" or "case anything:" or "case i_dont_care:" all do basically the same thing (although they bind to the given name, while _ does not bind to anything, but of what practical importance is that?) .
"|" is also a fine way to express alternatives. "case" has its own sub-language with its own rules, and "|" is widely used to express alternatives (whether in regexps, formal grammars, ...). Spell it, e.g., "or", and then I wonder "what does short-circuiting have to do with it?". All reuse of symbols carries baggage.
Well, the PEP says the alternatives are short-circuiting, so it's okay if you notice. ;-) Besides which, if we use "|" instead of "or" then we can't later allow more general expressions.
".NAME" grated at first, but extends the idea that dotted names are always constant value patterns to "if and only if". So it has mnemonic value.
How do you get from "." to "iff" ? -- ~Ethan~ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LFQYZDGDZ7SIMUSZYXXYTVIOV2LAKZW5/ Code of Conduct: http://python.org/psf/codeofconduct/
