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.