case foo():
would have to become
case (foo(),):
to work as expected when foo() returned a tuple, which would mean
wrapping things in 1-tuples whenever you wanted to reliably match a
case that is determined dynamically.
It may be just me, but I fail - in a complete manner - to see how this
syntax can offer any
improvement on current if/elif chains. It seems to differ from that
only by reducing
the explicitness, and the flexibility of the test condition that can
be used in any
of the subconditions
No it isn't. First, the "for ... in" keywords are not the same as just "for" and a bunch of parens and semicolons.
Also, notice that if you try to read the switch statement, or your Python version, as English, it's nonsense.
Bash doesn't have separate "case" and "elcase" cases. After one case is done, the rest are skipped, just as in most other languages.
I don't see how skipping over any elcase but falling through to the next case is in any way simpler than C.
Well, then at least look at the limited form of pattern matching Python has in the for and assignment statements and parameter matching, and maybe look at how pattern matching is used with case statements in other languages; don't try to suggest language designs based on guesses.
... and? Are you suggesting that if the switch expression is a string and the case expression a compiled regex you could automatically call match instead of testing for equality? If not, how is having regexp even relevant here? And how are recursive functions relevant?
A generator expression is equal to anything except itself, and doesn't contain anything.
I don't know what you mean by "symbolic pattern" here.