![](https://secure.gravatar.com/avatar/047f2332cde3730f1ed661eebb0c5686.jpg?s=120&d=mm&r=g)
On Wed, Jul 8, 2020 at 7:23 PM Rob Cliffe <rob.cliffe@btinternet.com> wrote:
*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:
The problem with this is that value patterns don't just appear at the top level. Consider this example from the PEP's deferred ideas section: case BinaryOp(left=Number(value=x), op=op, right=Number(value=y)): Using your notation, this would become: case BinaryOp(left=Number(value===x), op===op, right=Number(value===y)): The tokenizer, which is eager, would interpret '===' as '==' followed by '=' and it would treat this as a syntax error. Also, it looks a lot like a JavaScript equivalency (?) operator. A single '=' prefix suffers from pretty much the same thing -- Python's tokenizer as well as the tokenizer in most people's heads would read 'x==op' as containing '=='. Please drop it. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>