On 19 April 2014 06:54, Andrew Barnert abarnert-at-yahoo.com | python-ideas-at-python.org| 3en9kh2cbt@sneakemail.com wrote:
switch mystring case "spam": process(thingy)
That is not even remotely interpretable as an English sentence. That's not a problem for C, but it is for Python.
I'll think about a possible solution.
I don't see how skipping over any elcase but falling through to the next
case is in any way simpler than C.
Well, because it's coherent with if-elif. See my last example in my first message.
No it isn't. An elif clause is embedded in an if statement; there is no if clause you can embed on an if statement, just an entirely new and unrelated if statement.
I can assert, without fear of contradictions, that my proposed syntax is the closest to the if-elif syntax of all the switch statement proposed until now in the age of Python.
About off-topic arguments:
bash does not have either ";;&" or ";&"
http://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.htm...
Who asked you about list comprehensions or lambdas? What do you think they
have to do with anything? [...] I have no idea why you think recursive functions are relevant to anything being discussed here. [...]your proposal was to treat tuples specially and match all other iterables as single values, which means that a generator expression would be matched as a single value, meaning it would only match itself. And again, I don't understand what the relevance is supposed to be.
I premise that pattern recognition is outside the scope of my switch proposal. Anyway:
1. About list comprehensions and lambdas, you talked about assignment statements, and AFAIK the only pattern matching things that are somewhat related to assignment statement are the possibility to filter a list comprehension and the use of lambdas. If you mean something different you should be more explicit, instead of saying "what? where? why?" 2. About recursive function, I wronged. Sorry but it was late. 3. About generators, you can create a generator, convert it to an iterable and unpack it in a case_expr. I could also extend the current syntax and support a "generator unpacking". This way you'll have a limited alternative to pattern matching in some cases in a switch statement without the need to create a static iterable.