On 27 November 2017 at 16:05, Chris Angelico <rosuav@gmail.com> wrote:
On Tue, Nov 28, 2017 at 2:35 AM, Steven D'Aprano <steve@pearwood.info> wrote:
In this case, there is a small but real benefit to counting the assignment targets and being explicit about the number of items to slice. Consider an extension to this "non-consuming" unpacking that allowed syntax like this to pass silently:
a, b = x, y, z
That ought to be a clear error, right? I would hope you don't think that Python should let that through. Okay, now we put x, y, z into a list, then unpack the list:
L = [x, y, z] a, b = L
That ought to still be an error, unless we explicity silence it. One way to do so is with an explicit slice:
a, b = L[:2]
I absolutely agree with this for the default case. That's why I am ONLY in favour of the explicit options. So, for instance:
a, b = x, y, z # error a, b, ... = x, y, z # valid (evaluates and ignores z)
Agreed, only explicit options are even worth considering (because of backward compatibility if for no other reason). However, the unpacking syntax is already complex, and hard to search for. Making it more complex needs a strong justification. And good luck in doing a google search for "..." if you saw that code in a project you had to maintain. Seriously, has anyone done a proper investigation into how much benefit this proposal would provide? It should be reasonably easy to do a code search for something like "=.*islice", to find code that's a candidate for using the proposed syntax. I suspect there's very little code like that. I'm -1 on this proposal without a much better justification of the benefits it will bring. Paul