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 <ros...@gmail.com> wrote:
> On Sun, Jul 5, 2020 at 12:03 PM Shantanu Jain <hauntsani...@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-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/T24W2FZ6UY36CI2GP4LKGBSLSHBYH4K3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
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/YFGOGWIKXWT3REL335WOR4ZTQMJC7SXL/
Code of Conduct: http://python.org/psf/codeofconduct/
