On Thu, Nov 30, 2017 at 11:21:48AM +1300, Greg Ewing wrote: > It seems that many people think about unpacking rather > differently from the way I do. I think the difference > is procedural vs. declarative. > > To my way of thinking, something like > > a, b, c = x > > is a pattern-matching operation. It's declaring that > x is a sequence of three things, and giving names to > those things. It's not saying to *do* anything to x.
I hadn't thought of that interpretation before, but now that Greg mentions it, its so obvious-in-hindsight that I completely agree with it. I think that we should promote this as the "one obvious" interpretation. Obviously as a practical matter, there are some x (namely iterators) where you cannot extract items without modifying x, but in all other cases I think that the pattern-matching interpretation is superiour. > With that interpretation, > > a, b, ... = x > > is declaring that x is a sequence of at least two > items, and giving names to the first two. The ellipsis > just means that there could be more items, but we > don't want to give them names. Indeed. > On the other hand, some people seem to be interpreting > the word "unpack" as in "unpack a suitcase", i.e. the > suitcase is empty afterwards. But unpacking has never > meant that in Python! If it did, then > > x = [1, 2, 3] > a, b, c = x > > would leave x == [] afterwards. > > The only case where unpacking behaves like that is when > the rhs is an iterator rather than a sequence, in which > case a side effect is unavoidable. The question then is > what the side effect should be. > > I would argue that, since the side effect is something > that's not really wanted, it should be as *small* as > possible. By that argument, > > a, b, ... = some_iterator > > should do as *little* as possible to fulfill what's > being asked, i.e. give names to the first two items > produced by the rhs. Consuming those two items is > unavoidable, but there's no need to consume any more. I'm still in 100% agreement with all of this. > As for the "extra syntax", we only need it because we've > defined the existing unpacking syntax to imply verifying > that the rhs has exactly the same length as the pattern. > > We now want to express patterns which don't impose > a length constraint, so we need to write them some > other way. To be clear, I'm still luke-warm on the need for this, I think islice is adequate, but if others believe this is a use-case important enough for a syntactic solution, I've come around to making ... my prefered syntax. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
