On Sat, Jul 18, 2020 at 09:25:45AM -0000, emmanuel.coirier@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 that
using an undifferentiated name by itself in the match/case construct
will 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 strong
points 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