A more generalized switch statement for Python?

Posted Jul 8, 2016 15:44 UTC (Fri) by gasche (subscriber, #74946)
Parent article: A more generalized switch statement for Python?

Algebraic type and pattern-matching were introduced in the 1970s by the functional language Hope, and were quickly adopted by the ML languages (SML, OCaml, Haskell, F#, etc.; with a graceful adaptation to the object-oriented programming as sealed classes in Scala). I find that the discussions related in this article give the impression of the Python community as rather closed-minded as far as language design is concerned. For an interesting take on the form of programming language illiteracy fostered by self-contained one-language communities, see

Why I hate advocacy
Mark-Jason Dominus, 2000
http://www.perl.com/pub/2000/12/advocacy.html

A more generalized switch statement for Python?

Posted Jul 9, 2016 4:28 UTC (Sat) by marcH (subscriber, #57642) [Link] (2 responses)

Once you've seen in action ML-like pattern matching in some random language (from the ML family or not) and caught actual bugs thanks to it, then people claiming that if/elif/else is "The One Obvious Way to Do It" really sound like they're from the distant past. Maybe still trying to do large-scale development in assembly or something.

Quite surprising from Python: an otherwise fairly high-level language.

A more generalized switch statement for Python?

Posted Jul 10, 2016 18:19 UTC (Sun) by HIGHGuY (subscriber, #62277) [Link] (1 responses)

Pattern matching in those languages is great... because of the very strong typing (and automatic type deduction).
Putting this kind of matching with python's duck-typing is like trying to have your cake and eat it too. It's just going to cause even more subtle bugs that are hard to diagnose or find.

A more generalized switch statement for Python?

Posted Jul 10, 2016 20:14 UTC (Sun) by flussence (guest, #85566) [Link]

The very least they could do here is learn to not repeat the mistakes Perl 5 did in trying to add a switch construct to the language.

The examples given all look very *pretty*, which is what one would expect Python culture to focus on, but they're harder to *understand*.