On Apr 19, 2014, at 10:54, "Lucas Malor" <7vsfeu4pxg@snkmail.com> wrote:

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.

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 ";&"

http://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html

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.
[...]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.

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.

Anyway:
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?"

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.
About 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.