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:

FOO = 1
value = 0

match value:
    case %(FOO):  # This would not be matched
        ...
    case BAR:    # This would be matched
        ...

case {FOO}: …

case %(2 ** 10): ...

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: