> e.g., "or", and then I wonder "what does short-circuiting have to do
> with it?". All reuse of symbols carries baggage.
"or" brings an intuition of the execution order of pattern matching, just like how people already know about "short-circuiting".
"or" 's operator precedence also suggests the syntax of OR patterns.
As we have "|" as an existing operator, it seems that there might be cases that the precedence of "|" is not consistent with it in an expression. This will mislead users.
I prefer "or" to "|" as a combining token as there is nothing bitwise going on here. "or" reads better. Which is why Python used it for logic operations in the first place. It is simple English. "|" does not read like or to anyone but a C based language programmer. Something Python users should never need to know.
There is no existing pythonic way to write "evaluate all of these things at once in no specific order".
And in reality, there will be an order. It'll be sequential, and if it isn't the left to right order that things are written with the "|" between them, it will break someones assumptions and make optimization harder. Some too-clever-for-the-worlds-own-good author is going to implement __match__ classmethods that have side effects and make state changes that impact the behavior of later matcher calls (no sympathy for them). Someone else is going to order them most likely to least likely for performance (we should have sympathy for that).
Given we only propose to allow a single trailing guard if per case, using "or" instead of "|" won't be confused with an if's guard condition.
-gps