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.
On Sat, 4 Jul 2020 at 19:15, Chris Angelico rosuav@gmail.com wrote:
On Sun, Jul 5, 2020 at 12:03 PM Shantanu Jain hauntsaninja@gmail.com wrote:
- Finally, I did mention increasing the scope of constant value patterns to accommodate expressions (as opposed to just dotted names). If we were to do this, it’s a reason to prefer some syntaxes for constant value patterns over others.
I'm kinda theoretically in favour of expressions, but only the sort that logically "feel" like constants. Unary minus and the addition of real and imaginary parts are already supported, so what's still of value? IMO exponentiation of 2 is usually better spelled in hex (instead of 2**10, use 0x400, unless there's good reason), and since you can have underscores to break up an integer, that handles powers of 10 as well. What notations would you want to use?
ChrisA
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/T24W2FZ6... Code of Conduct: http://python.org/psf/codeofconduct/