[Python-ideas] Yet Another Switch-Case Syntax Proposal

[Andrew Barnert]

On Apr 18, 2014, at 7:42, "Lucas Malor" <7vsfeu4pxg at snkmail.com> wrote:
> 
>> On 17 April 2014 23:41, Andrew Barnert abarnert-at-yahoo.com |python-ideas-at-python.org| <3en9kh2cbt at sneakemail.com> wrote:
>> Any reason to use the keywords that only exist in C-family languages when the functionality isn't actually like C?
> 
> Well, it's the same for the "for" statement.

No it isn't. First, the "for ... in" keywords are not the same as just "for" and a bunch of parens and semicolons. If you just mean the word "for" itself, the exact same word is used in a wide variety of languages that have nothing to do with C, and some of them use it with the same meaning as Python. 

By contrast, most languages that are not related to C don't spell this statement "switch ... case ..."; the most common is probably "case ... of ..." or "case ... in ...".

Also, notice that if you try to read the switch statement, or your Python version, as English, it's nonsense. Compare that to for, while, if, try, etc. While there are some oddities (like condensing "else" and "if" into "elif"), as a general rule they make sense. That's not even remotely true with a C for statement.

>> > - if case_expr is not a tuple, the case suite will be executed if switch_expr == case_expr
>> > - if a case_expr is checked, any subsequent elcase statements are skipped, and the next case statement is performed, of there's one. This is completely identical to if - elif.
>> 
>> While you can figure out what this means with a bit of work, it seems to add a lot of conceptual complexity, and I can't think of any other language that does this.
> 
> 
> Bash case statement is similar.

Bash doesn't have separate "case" and "elcase" cases. After one case is done, the rest are skipped, just as in most other languages. 

> IMHO this syntax is very simple, simpler than C-like switch statements. Why do you think it is complex?

C cases always fall through to the next case. Almost every other language only executes a single case. I don't see how skipping over any elcase but falling through to the next case is in any way simpler than C.

>> why not consider features that other languages do have, like pattern matching cases?
> 
> I do not know much about pattern matching.

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.

> Using my little knowledge, Python have recursive functions and regular expressions.

... 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?

> You could also use generator expressions with my switch statement proposal.

How? Where? A generator expression is equal to anything except itself, and doesn't contain anything.

> Symbolic pattern is powerful, but it's a bit too much for this little proposal.

I don't know what you mean by "symbolic pattern" here.

>> if you want to match (1, 'b') you'd have to write case ((1, 'b'),). Which is bad for static cases, and even worse for dynamic ones.
> 
> Yes, it's not so elegant, but I do not think that it will really matters in real world usage.

Really? Have you never wanted to switch on the results of a function that returns two values?

> What do you mean exactly with "dynamic cases"?

Exactly what it sounds like: when the case value is a variable set somewhere else in the program, possibly by some program calling my library or even selected by user input or config, so at the point of the switch statement you (meaning a reader of the code) have no idea whether the value is a tuple; it's just some variable or lookup expression or the like.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140418/95956bc8/attachment-0001.html>