<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, May 23, 2016 at 8:23 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">No, what I'm saying is that seeing it as sugar for exception handing<br>
is the wrong way to look at it.<br></blockquote><div><br></div><div>Ok, let me refocus on the idea of assign-if-you-can during matching, not just sugar for try/except.</div><div><br></div><div>The matching features of equality, inequality, predicates, and subtype are already available via if/elif. The matching features of destructuring, assignment, and post-assignment guards need new syntax. The other proposals in this thread suggest a new keyword or keyword pair like switch/case. Instead, why not extend if/elif with a new operator?</div><div><div><br></div><div><div>def demo(arg):</div><div>    if p, q ?= arg.x, arg.y:                        # dict structure</div><div>    elif x ?= arg.x and isinstance(x, int)          # assignment + guard</div><div>    elif a, b, *_ ?= arg:                           # tuple structure</div><div>    elif isinstance(arg, Mapping):                  # nothing new here</div></div></div><div><br></div><div><br></div><div>A major advantage to merging these new matching features with the existing if/elif is that refactoring gets much easier. One could insert a single elif block near the top of the chain using the new assign-if-you-can operator/keyword, without needing to change any of the existing elif statements.</div><div><br></div><div>Otherwise, I could imagine someone waffling back and forth between switch/case and if/elif as they add and remove cases. What would be the style recommendation if you have 5 boring cases that are all easy to read via if/elif?</div><div><br></div><div>The disadvantage would be that the new syntax wouldn't stand out as much as it would with, say, switch/case, and someone might not notice its usage. I think a good choice of operator/keyword mitigates this. A keyword like ``as`` would stand out due to syntax highlighting. An operator like ``?=`` looks different enough and many similar-looking operators, like ``/=`` would be illegal.</div><div><br></div><div>Operator precedence would affect the beauty of the code.<span style="line-height:1.5"> Giving ``?=`` the same precedence as ``==`` seems best for post-assignment guards.</span></div></div></div>