<div dir="ltr"><div><div><div><div>why the unpacking has to happen automatically? <br><br></div>I would prefer something like:<br><div style="margin-left:40px">switch *args:<br></div><div style="margin-left:80px">case:...<br></div><br></div>Also I'm not a big fan of adding two new keywords to the syntax, I would think something like:<br><br><div style="margin-left:40px">switch *args:<br></div><div style="margin-left:40px"> &(a==1, ...) as a, *b:<br></div><div style="margin-left:80px"><div style="margin-left:40px"># code<br></div></div><div style="margin-left:40px"><div style="margin-left:40px">&(a,b) as a, b:<br></div></div><div style="margin-left:120px"># code<br></div><div style="margin-left:40px"><div style="margin-left:40px">&(a,b, ...) as a, b, *c:<br></div></div><div style="margin-left:120px"># code<br></div><div style="margin-left:80px">&(...) as a:<br></div><div style="margin-left:80px"><div style="margin-left:40px"># code<br></div></div><div style="margin-left:40px"><br></div></div>This
would reduce the numbers of new keywords needed to 1, it would make
sense to use the & operator because all the conditions have to be
TRUE and this use at the moment raises SyntaxError.<br></div><div>For how I see it could also make sense to be able to pass the arguments to a callable.<br></div><br>switch *args:<br> &(a==1, ...): (lambda a, *b: ...)<br><div style="margin-left:40px">&(a,b): (lambda a, b: [a, b])<br></div>&(a,b, ...): (lambda a, b, *c: [ a+1, b+1, *c])<br>&(...) as a: (lambda *a: [*a])</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 20, 2016 at 4:37 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 19 May 2016 at 14:15, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> The attribute idea would be similar to a duck-type check, though more<br>
> emphasizing data attributes. It would be nice if we could write a<br>
> match that said "if it has attributes x and y, assign those to local<br>
> variables p and q, and ignore other attributes". Strawman syntax could<br>
> be like this:<br>
><br>
> def demo(arg):<br>
> switch arg:<br>
> case (x=p, y=q): print('x=', p, 'y=', q)<br>
> case (a, b, *_): print('a=', a, 'b=', b)<br>
> else: print('Too bad')<br>
<br>
</span>For the destructuring assignment by attribute, I'd suggest the "value<br>
as name" idiom, since it's not quite a normal assignment, as well as a<br>
leading "." to more readily differentiate it from iterable unpacking:<br>
<br>
def demo(arg):<br>
switch arg:<br>
case (.x as p, .y as q): print('x=', p, 'y=', q)<br>
<span class=""> case (a, b, *_): print('a=', a, 'b=', b)<br>
else: print('Too bad')<br>
<br>
</span>Whether to allow ".x" as a shorthand for ".x as x" would be an open question.<br>
<span class=""><br>
> Someone else can try to fit simple value equality, set membership,<br>
> isinstance, and guards into that same syntax.<br>
<br>
</span>For these, I'd guess the most flexible option would be to allow the<br>
switch expression to be bound to a name:<br>
<br>
switch expr as arg:<br>
case arg == value: ...<br>
case lower_bound <= arg <= upper_bound: ...<br>
case arg in container: ...<br>
<br>
Similar to with statement and for loops, this wouldn't create a new<br>
scope, it would just bind the name in the current scope (and hence the<br>
value would remain available after the switch statement ends)<br>
<br>
If we went down that path, then the "assign if you can, execute this<br>
case if you succeed" options would presumably need an explicit prefix<br>
to indicate they're not normal expressions, perhaps something like<br>
"?=":<br>
<br>
switch expr as arg:<br>
case ?= (.x as p, .y as q): print('x=', p, 'y=', q)<br>
case ?= (a, b, *_): print('a=', a, 'b=', b)<br>
case arg == value: ...<br>
case lower_bound <= arg <= upper_bound: ...<br>
case arg in container: ...<br>
<span class=""> else: print('Too bad')<br>
<br>
</span>Which would then have the further implication that it might also make<br>
sense to support attribute unpacking as the LHS of normal assignment<br>
statements:<br>
<br>
(.x as p, .y as q) = expr<br>
<br>
In a similar vein, item unpacking might look like:<br>
<br>
(["x"] as p, ["y"] as q) = expr<br>
<br>
And unpacking different structures might look like:<br>
<br>
switch expr:<br>
case ?= (.x as x, .y as y): ... # x/y as attributes<br>
case ?= (["x"] as x, ["y"] as y): ... # x/y as mapping<br>
case ?= (x, y): ... # 2-tuple (or other iterable)<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</div></div></blockquote></div><br></div>