Yet Another Switch-Case Syntax Proposal
Lucas Malor
3kywjyds5d at snkmail.com
Thu Apr 3 12:02:42 EDT 2014
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"
More information about the Python-list
mailing list