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 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 > >
_______________________________________________ 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/2EGPJJXDTAKQVSY75PBE3A7BWCBXAKMZ/ Code of Conduct: http://python.org/psf/codeofconduct/
