"Structural pattern matching" for Python, part 2
"Structural pattern matching" for Python, part 2
Posted Sep 11, 2020 13:27 UTC (Fri) by mathstuf (subscriber, #69389)In reply to: "Structural pattern matching" for Python, part 2 by milesrout
Parent article: "Structural pattern matching" for Python, part 2
This feels like one of those "cannot derive ought from is" statements. Is there any indication that something better than `isinstance` if-trees was explicitly rejected earlier in the language's design process? I'd expect the previous approach was "just treat it like a duck and if it quacks well enough, what do you care?", but with types now becoming more and more of a thing in general (even in Python), this seems like a natural thing to be considering around this time (to me at least).
Posted Sep 12, 2020 4:30 UTC (Sat)
by milesrout (subscriber, #126894)
[Link] (1 responses)
Yes. Switch statement suggestions have been rejected over and over again. Pattern matching proposals have been rejected before. 'if isinstance' isn't considered bad Python because it's *ugly* but because it's *bad design*. Dispatching on types is just not a good way to write code in a dynamically typed language. There is no - and can be no - exhaustiveness checking for example, to give just one example of why it's a problem.
>but with types now becoming more and more of a thing in general (even in Python), this seems like a natural thing to be considering around this time (to me at least).
Adding type annotations to Python is yet another example of the continual application of bad ideas to clutter up Python, done by people trying to roleplay as Haskell programmers. Pattern matching is the same thing. It's blatant cargo culting.
Posted Sep 16, 2020 16:02 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
That problem has nothing to do with pattern matching and everything to do with dynamic typing, which is quite simply an inherently bad idea.
"Structural pattern matching" for Python, part 2
"Structural pattern matching" for Python, part 2