Re: Yet Another Switch-Case Syntax Proposal
On 6 April 2014 20:07, Chris Angelico rosuav-at-gmail.com |python-list@python.org| d7v3zta...@sneakemail.com wrote: Here's a simpler form of the proposal, which might cover what you need. It's basically a short-hand if/elif tree. case expression comp_op expression: suite case [comp_op] expression: suite else: suite I like this solution, but I tought about a simpler one. Basically it's my first proposal with two modifications: 1. case / elcase instead of continue, as before 2. if the case expression is a *tuple* (and not any one iterable), case suite is executed if the switched expression is an element of the tuple. If you want to match exactly a tuple, you have simply to put it into another tuple of length 1. Tricky but too much rare to care about. To recap: switch_stmt ::= switch expression case expression_list : suite (case | elcase expression_list : suite)* [else : suite] 1. if expression_list is a tuple, the case suite will be executed if the switch expression is a member of the tuple. 2. if expression_list is not a tuple, the case suite will be executed if the switch expression is equal Example: briefing_days = (Tue, Thu) normal_days = (Mon, Wed, Fri) switch day 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 Another example: switch tarot case 0: card = Fool case 1: card = Alan Moore case 2: card = High Priestess etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Yet Another Switch-Case Syntax Proposal
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 -- https://mail.python.org/mailman/listinfo/python-list
Yet Another Switch-Case Syntax Proposal
Hi all. I would proposeto you all a switch-case syntax for Python. I already read PEP 3103 and I'm not completely satisfied by any of the proposed solutions. This is my proposal: switch_stmt ::= switch identifier case expression_list : suite (case expression_list : suite)* [else : suite] or, more simply: switch x case var1: case var2: ... case var3: ... else: ... Expression list should yield an iterable. The case suite will be executed if the variable of the identifier is a member of the iterable. For example, in a switch x statement, the code case iterable: is identical to if x in iterable: (or elif etc). So if you want to perform the same case block for more than one value, you have only to specify a tuple, a range etc. I would suggest to add an exception for non-iterable variables, so that you don't have to write case var, : but simply case var: and it will be identical to if x == var: . It's a bit tricky but the alternative is ugly. Fallthrough is disabled by default. The continue keyword cause to skip all the remaining current case suite. The next case will be checked. You can't use the continue keyword in the else clause. Some random remarks: 1. switch is on the same line of the first case. This will avoid any unpythonic syntaxes like: switch x case var1: ... or switch x: case var1: ... 2. Fallthrough is disabled by default because IMHO it's what non-programmers expect and that's what programmer usually needs more. I don't think a switch with such a syntax needs a break statement. 3. As an alternative, the continue statement could be written only at the end of a case suite; it will be less powerful and not consistent with the other compound statements, but it will improve readability. 4. I decided to not use already existing keyword like if or in, since it will be misleading and problematic for syntax highlighters. Tell me what you think about. -- https://mail.python.org/mailman/listinfo/python-list
Re: Problem with getting an option value
Peter Otten wrote: Lucas Malor wrote: The problem is options is an instance, so options.delete, for example, is wrong; I should pass options.delete . How can I do? Use getattr(): Thank you. Do you know also if I can do a similar operation with functions? I want to select with a string a certain get() function of ConfigParser: if type == int : funcname = getint elif type == bool : funcname = getboolean etc. How can I invoke the funcion with its name in a string? PS: your answers had not arrived to my mail account. Is because I'm using a disposal address? Or simply it's because I'm not registered to the list? -- Protect yourself from spam, use http://sneakemail.com -- http://mail.python.org/mailman/listinfo/python-list
[optparse] Problem with getting an option value
Hello all. I'm trying to do a little script. Simply I want to make a list of all options with them default values. If the option is not specified in the command line, the script must try to read it in a config.ini file. If it's not present also there, it must set the default value. The problem is I maked a simple list for this: optname = [ [ delete, False ], [ file, file ], [ dir, ], But I must check that the option was specified in command line: (options, args) = parser.parse_args() for opt in optname : if not options.opt[0] : # read the options from config.ini The problem is options is an instance, so options.delete, for example, is wrong; I should pass options.delete . How can I do? -- Protect yourself from spam, use http://sneakemail.com -- http://mail.python.org/mailman/listinfo/python-list
