On Fri, 17 Jul 2020 at 12:28, Gustavo Carneiro <gjcarneiro@gmail.com> wrote:
On Fri, 17 Jul 2020 at 12:26, <emmanuel.coirier@caissedesdepots.fr> wrote:
Hello everyone, (...) But... looking at the examples, it wasn't very obvious that some variables were catching variables and some others were matching ones. I then read in details some rules about how to discover what is a captured variable. But I'm not sure everybody will do this...
Zen of Python tells us that "explicit is better than implicit". I know this is not a rule written in the stone, but I think here, it applies very well.
I Also dislike the idea of undotted names being assigned, with not extra visual clues, and the scenario described by Emmanuel, in the other e-mail about people changing variables when they think they are making a match (essentially introducing the _same_ problem that `if (SPAM = 0):` had in C which Python used to justify assignment not being an expression for over 20 years). So, in adding to the bikeshed color possibilities, alongside the "x=, y=" in this first e-mail or the "_ as x, _ as y" from Gustavo, I present the possibility of making the Walrus mandatory for capture. Maybe it is a bit "too much typing" - (Walrus will require 5-6 keystrokes with the surrounding spaces), but I think the final look can be pleasantly intuitive: match my_point: case (x := _, y := _) | Point2d(x := _, y := _): return Point3d(x, y, 0)
Guido said :
We’re really looking for a solution that tells you when you’re looking at an individual case which variables are captured and which are used for load-and-compare.
Marking up the capture variables with some sigil (e.g. $x or x?) or other markup (e.g. backticks or <x>) makes this common case ugly and inconsistent: it’s unpleasant to see for example
case %x, %y: print(x, y)
Guido talk about a "sigil", which seems to be a meaningless mark only here to help the parser understand what the dev was writing.
I propose that this "sigil" be the affectation mark : "=". Look :
z = 42 match pt: case x=, y=, z: print(x, y, "z == 42")
(...) Gustavo Carneiro <gjcarneiro@gmail.com> wrote:
I kind of agree it is nicer to be more explicit. But somehow x= looks ugly. It occurred to me (and, again, apologies if already been mentioned), we might use the `as` keyword here.
The example above would become:
def make_point_3d(pt): match pt: case (as x, as y): return Point3d(x, y, 0) case (as x, as y, as z): return Point3d(x, y, z) case Point2d(as x, as y): return Point3d(x, y, 0) case Point3d(_, _, _): return pt case _: raise TypeError("not a point we support")
If having "as x" as a standalone expression without anything to the left of "as" causes confusion, we could instead mandate the use of _ thus:
case (_ as x, _ as y): return Point3d(x, y, 0)