I daresay another issue is going to be the syntax -- the naïve way of implementing it nests two blocks: one for the pattern-matched block as a whole, and and another for the actual cases, which means that now you've got a double indent. IIRC this was a reason he gave against implementing case statements way back when.
There is one construct that's almost like a block but doesn't indent code, decorators. It's rich enough to implement multiple dispatch in functions, including pattern-matching on values and not just on types. Unfortunately it won't get you the sort of things you could do with actual blocks, e.g. access to other variables.
Pattern matching is very deeply ingrained into Elixir. Two examples to scratch the surface
This is pattern matching in function arguments
def process_file({:ok, {file_name, file_content}}) do
...
:ok
end
def process_file({:error, reason}) do
...
:error
end
def process_file(_), do: error
{:ok, content} = File.read(file_name)
Some changes are so structural that turn languages into another one and I'm not sure it's worth it. We have so many languages to choose from.
It's simple, it was added to counter-balance the smug ascertainment of Guido's ignorance, and the taken-for-granted assumption that we'd be so much better if he modeled Python more after ML/Lisp/etc.
>do you honestly think python, as a programming language, is superior to something like racket or f#?
No, I think the subject is moot. Python has been adopted and is widely successful for being Python.
We had MLs and Schemes/Lisps available before and after Python and they didn't manage to get traction. Why do you think having the original Python be more like these would help its case?
Even if the result was a "better language" in the sense you think Racket or F# are, those are still niche, and there's all the reasons to believe Python would be too if it followed their model.
So, it's not "if only Python was ML/Lisp like we would now have an equally successful but better Python!".
It's more likely "if Python was ML/Lisp it would still be niche today, and we wouldn't have a language with the characteristics that people love in Python and adopted it for, but yet another ML or Lisp version".
(a, (b, *c, d), *e) = [1, (2, 3, 4, 5), 6, 7]
http://www.dai.ed.ac.uk/groups/ssp/bookpages/quickprolog/nod...
[Amused to see that the page I linked to there is over 20 years old!]
When I first read that, I thought he meant run-time lookups of overloaded method names, which is a form of pattern matching on parameter lists.
https://www.artima.com/weblogs/viewpost.jsp?thread=101605
Five-minute Multimethods in Python, by Guido van van Rossum.
I used to believe that multimethods were so advanced I would never need them. Well, maybe I still believe that, but here's a quick and dirty implementation of multimethods so you can see for yourself. Some assembly required; advanced functionality left as an exercise for the reader.
https://python-3-patterns-idioms-test.readthedocs.io/en/late...
https://pythonhosted.org/multidispatch/
https://adambard.com/blog/implementing-multimethods-in-pytho...
https://opendylan.org/documentation/intro-dylan/multiple-dis...
https://opendylan.org/documentation/intro-dylan/objects.html...
say &infix:«+».candidates.elems; # 27
#! /usr/bin/env perl6
use v6.d;
enum Roshambo < Rock Paper Scissors >;
enum Outcome < Lose Win Draw >;
proto compete ( Roshambo, Roshambo --> Outcome ){*}
multi compete ( Paper, Rock --> Win ){}
multi compete ( Rock, Scissors --> Win ){}
multi compete ( Scissors, Paper --> Win ){}
multi compete ( $a, $b where $b eqv $a --> Draw ){}
multi compete ( $, $ --> Lose ){}
for Roshambo.roll(20) Z Roshambo.roll(20) -> ($a,$b) {
say "$a.fmt('%8s'), $b.fmt('%8s'): &compete($a,$b)"
}