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.
- 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.