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; - My suggestion was explicitly just bikeshedding syntax for constant value patterns (the “slightly more flexible switch” part of PEP 622). - The relative verbosity as compared to dot prefix syntax is meant as a feature, since it’s very easy to miss the dot - If you’re a proponent of dot syntax, you won’t see any value in this suggestion. Given that dot syntax seemed to come up in the thread a fair amount, and that the PEP calls it the “trickiest item”, I thought it might be worth suggesting some other options. - 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.
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:
- 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
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/
-
Chris Angelico -
Emily Bowman -
Shantanu Jain