<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 23, 2016 at 7:13 PM Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, May 23, 2016 at 3:49 PM, Michael Selik <<a href="mailto:michael.selik@gmail.com" target="_blank">michael.selik@gmail.com</a>> wrote:<br>
><br>
><br>
> On Mon, May 23, 2016 at 3:58 PM Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br>
>><br>
>> On Mon, May 23, 2016 at 11:45 AM, Joao S. O. Bueno<br>
>> <<a href="mailto:jsbueno@python.org.br" target="_blank">jsbueno@python.org.br</a>> wrote:<br>
>> > I still fail to see what justifies violating The One Obvious Way to Do<br>
>> > It which uses an if/elif sequence<br>
>><br>
>> Honestly I'm not at all convinced either! If it was easy to do all<br>
>> this with a sequence of if/elif clauses we wouldn't need it. The<br>
>> problem is that there are some types of matches that aren't so easy to<br>
>> write that way, e.g. combining an attempted tuple unpack with a guard,<br>
>> or "instance unpack" (check whether specific attributes exist)<br>
>> possibly combined with a guard. (The tricky thing is that the guard<br>
>> expression often needs to reference to the result of the unpacking.)<br>
><br>
> I figure it's better to solve the category of problems -- exception-catching<br>
> expressions -- rather than the single problem of catching exceptions in anĀ if/elif/else chain.<br>
<br>
People are likely either going to put in exceptions that don't catch<br>
enough (e.g. IndexError isn't the only exception that example can<br>
throw) or, overreacting to that problm, that catch everything ("except<br>
Exception:" is an anti-pattern that's hard to fight).<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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?</div></div></div>