Thank you for this PEP! Pattern matching is really exciting.
As the PEP mentions and the thread evidences, the current dot syntax for the “constant value pattern” is a tricky point. Given this, I thought I’d throw another suggestion into the bikeshed.
Use percent placeholder to indicate lookup (or even eval) semantics for a given name. For example:
FOO = 1
value = 0
match value:
case %(FOO): # This would not be matched
...
case BAR: # This would be matched
...
I like this syntax because it’s reminiscent of named substitution in percent formatted strings. It suggests a substitution / placeholder metaphor that is quite fitting. It has the benefit of not introducing a new symbol into Python and being explicit and hard to miss, including in nested contexts.
Note, it seems like it would also be technically possible to use curly braces (the more idiomatic means of named substitution in Python 3):
case {FOO}: …
The main downside of this is that it could look like some sort of singleton
“set pattern” (note that the PEP only supports “sequence patterns” and
“mapping patterns”).
(But set patterns maybe don’t quite make sense + if your set pattern had
multiple elements you’d still get a SyntaxError. For other examples where
something in Python looks like a set literal but isn’t, refer to {}
and
f-strings, so it’s maybe not the biggest stretch)
Both of these suggestions could also allow us more flexibility for constant value patterns, since currently there isn't a good way to match against a constant expression. For example, we could extend this syntax to allow us to express:
case %(2 ** 10): ...
I don't see how this extrapolates to arbitrary, extended match expressions? You're proposing a slightly more flexible switch, which match is only intended to be as the most basic case. Even if you purely swapped it out with any the various proposals for identifying a constant vs a target, it's still far more verbose than any of them.
On Sat, Jul 4, 2020 at 4:31 PM Shantanu Jain hauntsaninja@gmail.com wrote:
Thank you for this PEP! Pattern matching is really exciting.
As the PEP mentions and the thread evidences, the current dot syntax for the “constant value pattern” is a tricky point. Given this, I thought I’d throw another suggestion into the bikeshed.
Use percent placeholder to indicate lookup (or even eval) semantics for a given name. For example:
FOO = 1
value = 0
match value:
case %(FOO): # This would not be matched
...
case BAR: # This would be matched
...
I like this syntax because it’s reminiscent of named substitution in percent formatted strings. It suggests a substitution / placeholder metaphor that is quite fitting. It has the benefit of not introducing a new symbol into Python and being explicit and hard to miss, including in nested contexts.
Note, it seems like it would also be technically possible to use curly braces (the more idiomatic means of named substitution in Python 3):
case {FOO}: …
The main downside of this is that it could look like some sort of
singleton “set pattern” (note that the PEP only supports “sequence
patterns” and “mapping patterns”).
(But set patterns maybe don’t quite make sense + if your set pattern had
multiple elements you’d still get a SyntaxError. For other examples where
something in Python looks like a set literal but isn’t, refer to {}
and
f-strings, so it’s maybe not the biggest stretch)
Both of these suggestions could also allow us more flexibility for constant value patterns, since currently there isn't a good way to match against a constant expression. For example, we could extend this syntax to allow us to express:
case %(2 ** 10): ...
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/YQUCFREQ... Code of Conduct: http://python.org/psf/codeofconduct/
Apologies if I misunderstand anything, but my suggestion was just an alternative to the dot syntax for constant value patterns (which along with literal patterns are how PEP 622’s proposes to to cover the “more flexible switch” use case).
This syntax is more verbose than PEP 622’s dot syntax for identifying
constant value patterns, but that’s the intention. A number of messages in
the thread point out that the difference between case FOO: …
and case
.FOO: …
is very easy to miss.
There are a couple other proposals for how to identify constant value
patterns (and proposals for having constant value patterns be the default
and capture patterns be the ones explicitly demarcated).
The one suggested the most is case $FOO: …
. This is less verbose than my
suggestion, but a) it requires introducing a new symbol to Python, b) it
doesn’t correspond to any existing Python syntax, whereas syntax that’s
reminiscent of format strings might build on a shared substitution metaphor
in users’ minds.
The last two lines of my suggestion were just pointing out another potential reason to prefer this bikeshed over dot syntax (and others proposed at https://github.com/python/peps/blob/master/pep-0622.rst#alternatives-for-con... ): if we wanted to extend constant value patterns to match constant expressions (as opposed to just dotted names), having syntax that uses delimiters might be more readable than a dot or dollar prefix — at least to me it’s easier to parse a delimited region to see what part of a pattern would be matched against literally.
tldr;
On Sat, 4 Jul 2020 at 16:51, Emily Bowman silverbacknet@gmail.com wrote:
I don't see how this extrapolates to arbitrary, extended match expressions? You're proposing a slightly more flexible switch, which match is only intended to be as the most basic case. Even if you purely swapped it out with any the various proposals for identifying a constant vs a target, it's still far more verbose than any of them.
On Sat, Jul 4, 2020 at 4:31 PM Shantanu Jain hauntsaninja@gmail.com wrote:
Thank you for this PEP! Pattern matching is really exciting.
As the PEP mentions and the thread evidences, the current dot syntax for the “constant value pattern” is a tricky point. Given this, I thought I’d throw another suggestion into the bikeshed.
Use percent placeholder to indicate lookup (or even eval) semantics for a given name. For example:
FOO = 1
value = 0
match value:
case %(FOO): # This would not be matched
...
case BAR: # This would be matched
...
I like this syntax because it’s reminiscent of named substitution in percent formatted strings. It suggests a substitution / placeholder metaphor that is quite fitting. It has the benefit of not introducing a new symbol into Python and being explicit and hard to miss, including in nested contexts.
Note, it seems like it would also be technically possible to use curly braces (the more idiomatic means of named substitution in Python 3):
case {FOO}: …
The main downside of this is that it could look like some sort of
singleton “set pattern” (note that the PEP only supports “sequence
patterns” and “mapping patterns”).
(But set patterns maybe don’t quite make sense + if your set pattern had
multiple elements you’d still get a SyntaxError. For other examples where
something in Python looks like a set literal but isn’t, refer to {}
and
f-strings, so it’s maybe not the biggest stretch)
Both of these suggestions could also allow us more flexibility for constant value patterns, since currently there isn't a good way to match against a constant expression. For example, we could extend this syntax to allow us to express:
case %(2 ** 10): ...
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/YQUCFREQ... Code of Conduct: http://python.org/psf/codeofconduct/
On Sun, Jul 5, 2020 at 12:03 PM Shantanu Jain hauntsaninja@gmail.com wrote:
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
Caveats:
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:
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/