On Fri, 17 Jul 2020 at 12:28, Gustavo Carneiro <gjcarne...@gmail.com> wrote:
>
>
> On Fri, 17 Jul 2020 at 12:26, <emmanuel.coir...@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 <gjcarne...@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)
>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/EZGTHXOYTHRQ6JCEP7B26IA5RVGHEZAC/
Code of Conduct: http://python.org/psf/codeofconduct/
