[Python-ideas] Allow "assigning" to Ellipse to discard values.

[Rob Cliffe]

On 12/02/2015 18:15, Ethan Furman wrote:
> On 02/12/2015 06:58 AM, Rob Cliffe wrote:
>> On 11/02/2015 20:06, Greg Ewing wrote:
>>> Daniel Holth wrote:
>>>> How about zero characters between commas? In ES6 destructing
>>>> assignment you'd writes something like ,,c = (1,2,3)
>>> Wouldn't play well with the syntax for 1-element tuples:
>>>
>>>     c, = stuff
>>>
>>> Is len(stuff) expected to be 1 or 2?
>> Does that matter?
> Yes, it matters.  I have code that had better raise an exception if 'stuff' is not exactly one element.
>
>> In either case the intent is to evaluate stuff and assign its first element to c.
> No, its intent is to assign the only element to c, and raise if there are more, or fewer, elements.
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.)
>> 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
> a) That's ugly.
That's subjective.  (It may look like "grit on Tim's monitor", but it's 
*meaningful* grit, not grit required by overblown language syntax.)
> b) Special cases aren't special enough to break the rules.
I don't understand this comment.
>
>> 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!
> Uh, you're kidding, right?
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.
>
>> But making something "work" instead of raising an exception is likely to break much less code that changing/stopping
>> something from "working".
> It would break mine, so no thanks.
See above.  Your use case doesn't strike me as typical.
>
> --
> ~Ethan~
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4800 / Virus Database: 4257/9105 - Release Date: 02/13/15

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150217/043b992b/attachment-0001.html>