I don't want to discourage you too much, but I think that adding a switch statement comes *very* low on the list of improvements we would like to make in Python 3.5.
We should probably focus on speed (or aspects of it, like startup), language features that help porting Python 2 code to it (e.g. bytes formatting), and things that improve the user experience of getting started with Python on a new machine (e.g. pip/venv). Or perhaps stdlib issues like an asyncio-infused variation of WSGI.
I've probably missed a few focus areas, but I still very much doubt we'll be adding a switch statement -- it's a "sexy" language design issue (like anonymous functions) but that's not what will help Python compete.
On Thu, Apr 17, 2014 at 12:14 PM, Lucas Malor firstname.lastname@example.org:
Hello everybody. I firstly proposed this syntax in the python-list. As I already wrote there, I read PEP 3103 and I'm not completely satisfied by any of the proposed solutions.
My first idea was a little different, this is my final proposal after a short but good brainstorm:
switch_stmt ::= "switch" switch_expr "case" case_expr ":" suite ("case" | "elcase" case_expr ":" suite)* ["else" ":" suite] switch_expr ::= expression case_expr ::= expression_list
- if case_expr is a tuple, the case suite will be executed if switch_expr
is a member of the tuple
- 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.
briefing_days = ("Tue", "Thu") normal_days = ("Mon", "Wed", "Fri")
switch day case normal_days + briefing_days: go_to_work = True day_type = "weekday" case normal_days: lunch_time = datetime.time(12) meeting_time = datetime.time(14) elcase briefing_days: lunch_time = datetime.time(11, 30) meeting_time = datetime.time(12, 30) else: go_to_work = False day_type = "festive" lunch_time = None meeting_time =None
A simpler example:
switch tarot case 0: card = "Fool" elcase 1: card = "Alan Moore" elcase 2: card = "High Priestess" <etc....>
- switch is on the same line of the first case. This is because
alternatives in PEP 3103 seems unpythonic to me 2. I decided to not use already existing keywords like "if" or "in", since this will be misleading 3. I preferred case / elcase instead of using break or continue keyword because: a. break / continue can confuse, since they are used in loop statements, and this is not a loop statement, as Ethan Furman pointed out in the other mailing list b. break / continue is useful only if it can be used not only as final command, so you can skip the rest of the current case suite. If it must be the final command, it's the same of case - elcase. IMHO there's no much real need to allow this c. case - elcase syntax is much more readable and less confusing of a break / continue d. case - elcase syntax is identical to if - elif, so people will be more familiar with it 4. notice that you can put a "case" statement after an "elcase" one. For example:
switch cpu case "A6-6400K", "A8-6600K" clock = 3.9 elcase "A10-6790K", "A10-6800B" clock = 4.1 case "A6-6400K" tdp = 65 elcase "A8-6600K", "A10-6790K", "A10-6800B" tdp = 100
is equivalent to
if cpu in ("A6-6400K", "A8-6600K") clock = 3.9 elif cpu in ("A10-6790K", "A10-6800B") clock = 4.1
if cpu == "A6-6400K" tdp = 65 elif cpu in ("A8-6600K", "A10-6790K", "A10-6800B") tdp = 100 _______________________________________________ Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/