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-constant-value-pattern ): 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 <silverback...@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 <hauntsani...@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-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/YQUCFREQ2P7NENOTPBE277I3BZ6DGXSR/ >> 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/2HJ6QESZGQGJ6VL5LCKSDRI4NYRZOEVN/ Code of Conduct: http://python.org/psf/codeofconduct/
