On Mon, May 23, 2016 at 3:49 PM, Michael Selik <michael.selik@gmail.com> wrote:
>
>
> On Mon, May 23, 2016 at 3:58 PM Guido van Rossum <guido@python.org> wrote:
>>
>> On Mon, May 23, 2016 at 11:45 AM, Joao S. O. Bueno
>> <jsbueno@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
>>
>> 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.)
>
> I figure it's better to solve the category of problems -- exception-catching
> expressions -- rather than the single problem of catching exceptions in an if/elif/else chain.
People are likely either going to put in exceptions that don't catch
enough (e.g. IndexError isn't the only exception that example can
throw) or, overreacting to that problm, that catch everything ("except
Exception:" is an anti-pattern that's hard to fight).
It sounds like the justification for a switch/match syntax is to provide a special situation where generic Exception-catching assignment expressions are acceptable, because they're useful in a long elif chain but too dangerous for widespread use.
Clearly it's beneficial enough to have appeared in other languages. However, languages like Haskell have already accepted the danger of assignment (and more) being an expression. Is there a language that makes the expression/statement distinction that has as powerful a matching syntax?