Yet Another Switch-Case Syntax Proposal

[Lucas Malor]

Thank you for reading and commenting my proposal. Here are my replies:

In reply to Chris Angelico:

> I don't like the "iterable vs non-iterable" distinction. Compare: [...]
> case "Test": # And there's your problem.

Yes, I had already thought after I posted that testing against string it's a problem. But I think that the more practical and unambiguous solution is to introduce also "casein" as a new keyword. So if you want to test a string:

switch mystring case "-h":
    print_usage()
case "--version"
    print_version()

If you want to test against membership:

switch mychar casein "aeiou":
    mychar.vocal = True

I prefer "casein" instead of "case in" for the same reason Python uses "elif" instead of "else if".



In reply to Ian Kelly:

> A more suitable place to propose this would be the python-ideas mailing list.

You're right. I posted here because this list was linked by PEP 1. But now that I read more there's also python-ideas listed. Let me know if I have to continue there instead.

> Why just just an identifier after the switch keyword instead of an expression?

Because I wronged, it can be an expression_list as well.

> An expression_list is one or more independent expressions separated by commas that 
> don't create a tuple.

Well, py docs state "An expression list containing at least one comma yields a tuple".

> __contains__ is not part of the interface for iterables

For what I know there's not an Iterable interface. For example List simply extends Object. I hope that an ABC Iterable class will be introduced in a future. 
Anyway, I think that "switch x casein y" should simply raise a TypeError if y doesn't implement __contains__, like "x in y" do.

> If we overload the continue keyword in this way, then a continue can't be used within the switch
> to control a loop that the switch is nested within.

Well, this is the same problem for, say, a for loop nested inside another for loop, and you can solve it with the same methods.

> Instead of disabling fallthrough by default, why not disable it all together?

I was tempted but there are cases in which it's useful. An example

switch day casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
    gotowork = True
    continue
casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
    daytype = "ferial"
casein ("Saturday", "Sunday")
    daytype = "festive"