On 08/07/2020 16:02, Guido van Rossum wrote:

```
    USE_POLAR = "polar"
    USE_RECT = "rect"
```
Now we would like to be able to replace those literals with the
corresponding names throughout our code and have everything work like
before:
```
    match t:
        case (USE_RECT, real, imag):
            return complex(real, imag)
        case (USE_POLAR, r, phi):
            return complex(r * cos(phi), r * sin(phi))
```
Alas, the compiler doesn’t know that we want `USE_RECT` to be a
constant value to be matched while we intend `real` and `imag` to be
variables to be given the corresponding values captured from the
subject. So various clever ways have been proposed to distinguish the
two cases.
I apologise for posting a second message re the same idea, but I can't contain my enthusiasm for it:-)
and I want to make sure it's not overlooked:
Use '==' to mark (when necessary) load-and-compare items:
    match t:
        case (==USE_RECT, real, imag):
            return complex(real, imag)
        case (==USE_POLAR, r, phi):
            return complex(r * cos(phi), r * sin(phi))

allowing incidentally a possible future extension to other relational operators:
    case Point(x, >YMAX):
    case >= 42:


If this really is a deal-breaker after all other issues have been
settled, we could go back to considering some special markup for
load-and-compare of simple names (even though we expect this case to
be very rare). But there’s no pressing need to decide to do this now
-- we can always add new markup for this purpose in a future version,
as long as we continue to support dotted names without markup,
since that *is* a commonly needed case.

Except that if this idea were taken to its logical conclusion,
    mod.var        would be a capture variable (contrary to the PEP)
    ==mod.var    would be a load-and-compare value
Which may be controversial, but seems to have more overall consistency.