Consider alternative for '|'?

[gvanrossum]

A few people on python-dev don't seem to like or understand case 401|403|404:. A number of different alternative proposals have been made:

• case 401 or 403 or 404:

• case in 401, 403, 404:

• stacked cases:

  case 401:
  case 403:
  case 404:
  

The latter two don't extend well to nested patterns (which a number of people don't seem to grasp well) and the former seems unnecessarily more verbose, but at the very least we need to add these to Rejected Ideas.

[Delta456]

How about case 401, 403, 404?

[brandtbucher]

@Delta456 Please take the time to read the proposal and the comments by Guido and others. Your suggestion already has valid meaning as a sequence pattern, and cannot be nested.

[Delta456]

Sorry I meant to write case 401 or 403 or 404:. Hope its now clear @brandtbucher

[Tobias-Kohn]

@gvanrossum Agreed, case 401 | 403: and case 401 or 403: are the only really sensible alternatives that we should consider. The possibility to nest patterns is one of the key features and I frequently enough do and encounter things like, e.g., case f(3 | 4 | 5, x): in pattern matching.

The difference between or and | is, at the end of the day, rather a minor issue of micro-syntax. I quite prefer | over or in this context, but I could live with both.

[gvanrossum]

Yeah, or has also been brought up in the discussion of a better syntax for unions in PEP 604, although it's not in the "Rejected Ideas" section there. (The proposal as it stands uses int|str as a shorthand for Union[int, str].)

I also find that 0|1|2 (or 0 | 1 | 2) reads much better than 0 or 1 or 2, especially in nested patterns.

One reason (for me) is that in my mind I strongly associate or (as well as and and not) with if, as in if some_condition or some_other_condition: ..., and the associated shortcut behavior (which in my old mind, raised with C and Pascal, still translates into explicit JUMP operations :-). But all that is a distraction for patterns -- if anything, | there reminds me of the | operator used to choose between alternatives in a grammar, which is much closer as a concept than evaluating Boolean conditions.

[brandtbucher]

Yeah, I was originally very reluctant to use | (I was first introduced to it with case 0 | 1:, which immediately made me think of bitwise-or). But comparing other examples like .spam or .eggs or .cheese vs .spam | .eggs | .cheese makes it clear that the visual separation of | is a huge benefit over or.

[Delta456]

I now have to agree that | is better than or for this.

[gvanrossum]

I think our action item here is to write a sub-section for the Rejected Ideas section that explains why | is superior over or.

[thautwarm]

~~Using or allows us to implement the parser without adding a pattern rule ~~ using | can also avoid adding dedicated grammar rule for pattern.

Also, as "|" is already a python operator, I wonder if there is a case that precedence of "|" in a pattern is different from its in an expression?

[Tobias-Kohn]

@thautwarm As you have pointed out elsewhere yourself, we should first and foremost consider this from the user's perspective. That it might make the grammar slightly simpler is IMHO not a strong enough argument here—without having studied the grammar recently, I doubt that it is really that simple, anyway.

[brandtbucher]

@ambientnuance, your comments are totally off-topic here.

EDIT: Thanks for removing the messages.

[thautwarm]

@Tobias-Kohn Thanks, I now think | is quite okay. That is because the precedence is still correctly consistent to the use of | in an expression.

Come back to Guido's suggestion

I think our action item here is to write a sub-section for the Rejected Ideas section that explains why | is superior over or.

1. | is widely used in other languages for the same functionalities. This brings familiarity.
2. | is shorter, this may contribute to readability when it comes to nested patterns, and must make coding slightly easier.

   case C(C1() | C2(), C3()) | C4():
   case C(C1() or C2(), C3()) or C4())
   

3. | doesn't break the consistency with the existing grammar. The precedence of | used in patterns is the same as it used in expressions.
4. People working on every field will use or extremely frequently, hence they build an impression that or is strongly associated with boolean short circuits. A minority of Python users use | frequently, because | is bitwise operations. (EDIT : Usually) people who play with bitwise operations or its overload semantics are more of hackers/experts, both of or and | are consistent in some degree, hence those hackers and experts are open to accept new ideas.

EDIT: Drawbacks of | comparing to or:

1. In the history of python, | has no semantics for short circuiting but or does, where short circuiting indicates sone naturals of python pattern matching, such as execution order.

[DimitrisJim]

I might be missing something but, there's talk of or being associated with short-circuiting implying that | isn't. The PEP though does state that it is:

Alternatives are tried from left to right and have short-circuit property [...]

Maybe this point needs to be further clarified?

If | does exhibit short-circuiting, then, that does result in an unfortunate disconnect with __or__. I do believe though that anyone who implements __or__ and is aware of short-circuiting will be able to handle that disconnect.

Also @thautwarm, saying hackers/experts are open to new ideas implies that people not belonging in that group are not open to new ideas, which some people might take offence with.

I'm also in support of |, mainly because I've seen it in other languages and because it personally seems better suited as a visual separator, as Brandt pointed out. In short, I believe the decision of one versus the other will eventually boil down to subjective taste and it does seem that most subjective opinions here do seem to back |. (though if | does short-circuit in patterns, that difference between it and __or__ definitely bugs me in a minor way).

[thautwarm]

@DimitrisJim

saying hackers/experts are open to new ideas implies that people not belonging in that group are not open to new ideas, which some people might take offence with

Yes. I said a general case, but still many senior python users would reject certain changes and newbies/learners can he glad to accept changes. I just said a general case.

though if | does short-circuit in patterns, that difference between it and or definitely bugs me in a minor way

Fair. Instead of only pointing out "why | is superior", we'd also present the disadvantages of | under or.

It could better to show how we score the both according to the pros/cons in the PEP.

[Tobias-Kohn]

Here is another argument in favour of both | for OR-patterns as well as using _ as wildcard (issue #92).

When looking at pattern matching syntax in other languages, we find that both _ and | seem to have been established as a rather universal standard. I searched for pattern matching in C#, Elixir, Erlang, F#, Haskell, Mathematica, OCaml, Ruby, Rust, Scala, Swift, and Thorn (this list is certainly not complete). All of these languages use _ as wildcard in pattern matching! OR-patterns, on the other hand, are either expressed with | (in F#, Mathematica, OCaml, Ruby, Rust, and Scala), a comma , (C# and Swift), or || (Thorn). We cannot use the comma as OR-operator for obvious reasons (tuples!).

In general, we should not be concerned too much with what another language does, since Python is clearly different from all these languages. However, if there is such an overwhelming and strong consensus, I think Python should not go out of its way to do something completely different—particularly given that _ and | would work well in Python.

[DimitrisJim]

I think Python should not go out of its way to do something completely different

Exactly, It would definitely be silly to ignore the strong precedent set by all those languages. Following it will not only help users coming from those languages but also help users going to them. Pedagogy from #101 clearly applies here.

Going by the Design tenets (ignoring ones that apply to both), it's clear to me that for | both Pedagogy and All the other kids are doing it (i.e precedent) apply. In addition to this, I'd like to add the fact that | is indeed a superior visual separator. | cannot be used in names, or, of course, can be part of one. Seeing | directly translates to OR without further parsing. (I'll suppress my urge to supply a very contrived example.)

Playing the devil's advocate for or, I could see an argument for Consistency with other Python statement forms due to the short-circuiting behavior. I personally think this can be remedied by strong wording in an official tutorial that | has no association with __or__ nor or. That is, there's no boolean evaluation going on, | is a separator for alternatives and not much more.

[gvanrossum]

@Tobias-Kohn Mind reviewing https://github.com/python/peps/pull/1487? I cribbed a bunch from your comments here.