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: http://tom.loria.fr/wiki/index.php/Main_Page -- Steven