I'm very new to this mailing list so I'm not sure it's my place to email, but
I'd like to weigh in and maybe it will be useful. If not you can always ignore
;)
I think adding the Walrus operator is trying to solve a problem that doesn't
exist. Compare the example from the PEP:
def make_point_3d(pt):
match pt:
case (x, y):
return Point3d(x, y, 0)
case (x, y, z):
return Point3d(x, y, z)
case Point2d(x, y):
return Point3d(x, y, 0)
case Point3d(_, _, _):
return pt
case _:
raise TypeError("not a point we support")
To the one without:
def make_point_3d(pt):
match pt:
case (x := _, y := _):
return Point3d(x, y, 0)
case (x := _, y := _, z := _):
return Point3d(x, y, z)
case Point2d(x := _, y := _):
return Point3d(x, y, 0)
case Point3d(_, _, _):
return pt
case _:
raise TypeError("not a point we support")
It's a lot more typing, it's a lot more ugly, and I'd argue it's not any more
explicit than the earlier one. We still have all the same variables, except now
we have to follow them with a ritualistic ":= _" to capture them. Normally we
use the underscore to discard or hide something (at least that's how I've
always used it), and suddenly it is used when we want to keep the thing it
stands for?!
Also, I understand Python doesn't look like Haskell or Rust or whatever, but
you also have people coming from those languages to Python, and people going to
those languages from Python. Having a different syntax from what literally
everybody else does will lead to a lot of confusion. I think the default option
should be to have it like the current proposal (and everybody else), and update
it only if there is a good reason to do so. "We don't want to look like the
rest" should not be an argument. I think Python not looking like anything else
is a result of the readability and simplicity goals of Python, not because the
goal was to look different.
Finally, I asked an actual Python newbie (our trainee) about his opinion, and
he said he didn't think the walrus example was any more useful. Of course, N=1,
not an experiment, doesn't measure mistakes in practice, etc. But let's make
sure it's an actual problem before we go complicate the syntax.
Again, first time mailing here and I don't know if it's my place (can I even
mail into this list?), but I hope the perspective is of some use.
Rik
P.S. I never had issues with list comprehensions, because it's basically how
you write down sets in mathematics (which is what I studied).
"Joao S. O. Bueno" <jsbu...@python.org.br> wrote:
“”
“On Sat, 18 Jul 2020 at 14:12, Steven D'Aprano <st...@pearwood.info> wrote:”
“On Sat, Jul 18, 2020 at 09:25:45AM -0000, emmanuel.coir...@caissedesdepots.fr
wrote:
> This approach, for me, seems to come from functionnal languages where
> pattern matching is a thing. The proposed "match" clause tends to
> mimic this approach, and it can be a good thing. But the Python's
> function definition has not been inspired by functionnal programming
> from the ground, and I think it would be an error to reason this way,
> because people not used to pattern matching in functionnal programming
> won't understand anything (imagine that comprehension lists are a big
> thing for many learners).
It is true that beginners sometimes struggle a bit to grok comprehension
syntax. I know I did.
And yet, despite that, comprehensions have turned out to be one of the
most powerful and popular features of Python, sometimes *too* popular.
It is sometimes hard to convince both beginners and even experienced
devs that comprehensions are not the only tool in their toolbox, and not
every problem is a nail.
You say: "people not used to pattern matching in functionnal programming
won't understand anything" but people using Haskell weren't born knowing
the language. They had to learn it.
It's been sometimes said that functional programmers are smarter, elite
programmers a level above the average OOP or procedural programmer, but
that's mostly said by functional programmers :-) and I'm not entirely
sure that its true. In any case, I don't think that any (actual or
imaginary) gap between the ability of the average Haskell programmer and
the average Python programmer is so great that we should dismiss pattern
matching as beyond the grasp of Python coders.
In any case, functional languages like Haskell, F# and ML are not the
only languages with pattern matching. Non-FP languages like C#, Swift,
Rust and Scala have it, and even Java has an extension providing pattern
matching:”
“
You do a nice job arguing that matching is a nice feature to have - and I guess
we are past this point.
But I don't see one thing in the above characters pointing thatusing an
undifferentiated name by itself in the match/case constructwill be better than
trying to find a way to differentiate it,and having significant gains in
readability and "learnability"
Yes, people aren't born knowing Haskell, but then, one of the strongpoints in
Python is (or used to be) it _not looking_ like Haskell.
Having a differentiation sign for assignment would also allow matching against
values in variables just work in a very intuitive way,just like it would have
happened with the ".variable_name" in the first version.
(I've written another e-mail on the thread, but since this scatters around: my
current bikeshed color is to _require_ the walrus op for assignments like in:
`case (x := _, y := _): ...` )
js -><-”
“http://tom.loria.fr/wiki/index.php/Main_Page
--
Steven”
[attachment.txt]
_______________________________________________
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/HXTA7YSOIIMJPKYP5QK2IIH3CZA5VSMI/
Code of Conduct: http://python.org/psf/codeofconduct/
