[Python-ideas] Match statement brainstorm

[Guido van Rossum]

On Mon, May 23, 2016 at 11:45 AM, Joao S. O. Bueno
<jsbueno at python.org.br> wrote:
> I still fail to see what justifies violating The One Obvious Way to Do It which
> uses an if/elif sequence so blatantly beyond the
> feeble "Yet, some kind of switch statement is found in many languages
> and it is not unreasonable to expect that its addition to Python will
> allow us to write up certain code more cleanly and efficiently than
> before." in the rejected PEP.
>
> It is not like omitting the object reference name on the conditional
> expression (and therefore,
> a condition expression that is tied to one object)  is more readable at all.
>
> But them, it is the BDLF cming with the proposal - I am just this
> Python develoepr teacher, that just last Wednesday was saying
> something along on a crash course:
> "We don  need switch/case because it is just a special case of an
> if/elif sequence,
> that was meaningful when  C compilers did not had resources to optimize
> that themselves".
>
> I argue no further, if people still see this as desirable.Ths is just my plain
> Python user "-1" on python-ideas.

Honestly I'm not at all convinced either! If it was easy to do all
this with a sequence of if/elif clauses we wouldn't need it. The
problem is that there are some types of matches that aren't so easy to
write that way, e.g. combining an attempted tuple unpack with a guard,
or "instance unpack" (check whether specific attributes exist)
possibly combined with a guard. (The tricky thing is that the guard
expression often needs to reference to the result of the unpacking.)

It might become yet more interesting when combining the unpack syntax
with type annotations, so you could check e.g. whether there's an x
attribute that's a float and a y attribute that's a string.

But it's about the most speculative piece of language design I've
contemplated in a long time...

-- 
--Guido van Rossum (python.org/~guido)