<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 12/02/2015 18:15, Ethan Furman
wrote:<br>
</div>
<blockquote cite="mid:54DCEDCD.7080408@stoneleaf.us" type="cite">
<pre wrap="">On 02/12/2015 06:58 AM, Rob Cliffe wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 11/02/2015 20:06, Greg Ewing wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Daniel Holth wrote:
</pre>
<blockquote type="cite">
<pre wrap="">How about zero characters between commas? In ES6 destructing
assignment you'd writes something like ,,c = (1,2,3)
</pre>
</blockquote>
<pre wrap="">
Wouldn't play well with the syntax for 1-element tuples:
c, = stuff
Is len(stuff) expected to be 1 or 2?
</pre>
</blockquote>
<pre wrap="">
Does that matter?
</pre>
</blockquote>
<pre wrap="">
Yes, it matters. I have code that had better raise an exception if 'stuff' is not exactly one element.
</pre>
<blockquote type="cite">
<pre wrap="">In either case the intent is to evaluate stuff and assign its first element to c.
</pre>
</blockquote>
<pre wrap="">
No, its intent is to assign the only element to c, and raise if there are more, or fewer, elements.</pre>
</blockquote>
Hm. With respect, that doesn't seem to me like a common use case.
I would have thought that more often a mismatch between the number
of elements to be unpacked and the number of target variables would
be a bug. (OK, perhaps it is but you want the runtime to pick up
such bugs.)
<blockquote cite="mid:54DCEDCD.7080408@stoneleaf.us" type="cite">
<blockquote type="cite">
<pre wrap="">We could have a rule that when the left hand side of an assignment is a tuple that ends in a final comma then unpacking
stops at the final comma, and it doesn't matter whether there are any more values to unpack. (Perhaps multiple final
commas could mean "unpack until the last comma then stop, so
c,,, = stuff
</pre>
</blockquote>
<pre wrap="">
a) That's ugly.</pre>
</blockquote>
That's subjective. (It may look like "grit on Tim's monitor", but
it's *meaningful* grit, not grit required by overblown language
syntax.)<br>
<blockquote cite="mid:54DCEDCD.7080408@stoneleaf.us" type="cite">
<pre wrap="">
b) Special cases aren't special enough to break the rules.</pre>
</blockquote>
I don't understand this comment.<br>
<blockquote cite="mid:54DCEDCD.7080408@stoneleaf.us" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">would mean "raise an exception if len(stuff)<3; otherwise assign the first element of stuff to c".)
It could even work for infinite generators!
</pre>
</blockquote>
<pre wrap="">
Uh, you're kidding, right?</pre>
</blockquote>
No, I wasn't kidding. I was suggesting that only as many values as
required by the LHS should be extracted from the generator. So
there is no infinite loop even though the generator itself is
(potentially or actually) non-terminating.<br>
<blockquote cite="mid:54DCEDCD.7080408@stoneleaf.us" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">But making something "work" instead of raising an exception is likely to break much less code that changing/stopping
something from "working".
</pre>
</blockquote>
<pre wrap="">
It would break mine, so no thanks.</pre>
</blockquote>
See above. Your use case doesn't strike me as typical.<br>
<blockquote cite="mid:54DCEDCD.7080408@stoneleaf.us" type="cite">
<pre wrap="">
--
~Ethan~
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Python-ideas mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Python-ideas@python.org">Python-ideas@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/python-ideas">https://mail.python.org/mailman/listinfo/python-ideas</a>
Code of Conduct: <a class="moz-txt-link-freetext" href="http://python.org/psf/codeofconduct/">http://python.org/psf/codeofconduct/</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">-----
No virus found in this message.
Checked by AVG - <a class="moz-txt-link-abbreviated" href="http://www.avg.com">www.avg.com</a>
Version: 2014.0.4800 / Virus Database: 4257/9105 - Release Date: 02/13/15
</pre>
</blockquote>
<br>
</body>
</html>