On 19 April 2014 06:54, Andrew Barnert abarnert-at-yahoo.com
switch mystring case "spam":
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.
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 don't see how skipping over any elcase but falling through to the next case is in any way simpler than C.
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.
So what? All of those other syntaxes were rejected, and not because they weren't close enough to if-elif syntax.
And besides, that's not actually true. Look at how if statements are defined in the grammar. You've attempted to match the syntax of a sequence of separate if statements within a single statement.
About off-topic arguments:
bash does not have either ";;&" or ";&"
OK, I didn't know about this GNU extension. But it still doesn't answer any of my points. They are not the same as C break and continue, not are they the same as your proposed semantics. I won't repeat all the stuff you snipped out and didn't reply to, just the big one: you've cited bash and C as justification for your feature of skipping over some cases but then continuing to check others, but neither C not bash has any way to do that at all, much less a way that's similar to yours.
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.
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.
I already explained why it isn't. If you're looking to not just bring a case statement to Python, but invent a unique and more powerful one than any that have come before, you need to actually address what's come before. Especially since your syntax, by treating tuples specially, would prevent any future extensions along these lines, you need to explain why the multiple cases feature is more important than the pattern matching feature.
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?"
I still don't understand how you think filtering a list comprehension or using lambdas have anything to do with pattern matching, or what they have to do with assignment statements. Since you insist that you read up on what pattern matching means, I have no idea how to answer that.
Especiallly since I already showed you exactly what I mean:
x, y = expression()
This requires the expression to return an iterable of exactly two values, and assigns those two values to x and y, in a way that's a analogous to (a duck-typed version of) ML-style pattern matching syntax.
- About recursive function, I wronged. Sorry but it was late.
generators, you can create a generator, convert it to an iterable and
unpack it in a case_expr.
I already explained that a generator is already an iterable and doesn't need to be converted into one. Your proposed syntax doesn't have any way to unpack iterables, and I'm not sure what it would do if you added such a thing (especially since you want to treat inline tuple displays specially, but not normal tuples, much less other iterables or sequences).
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.
How does this provide an alternative to pattern matching? Show an example of what you mean.