On Wed, Nov 29, 2017 at 03:08:43PM -0800, Brendan Barnwell wrote:
> On 2017-11-29 14:21, Greg Ewing wrote:
> >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.
>
> That's an interesting analysis, but I don't think your view is
> really the right one. It *is* unpacking a suitcase, it's just that *if
> necessary* the suitcase is constructed just in time for you to unpack
> it. In other words, the suitcase is not the list [1, 2, 3], but an
> iterator over this list.
At the point that you are conjuring from thin air an invisible suitcase
that is an exact clone of the original suitcase, in order to unpack the
clone without disturbing the original, I think the metaphor is so far
from the real-world unpacking of suitcases that it no longer applies.
Besides, it's not even correct to say that an invisible suitcase
(iterator) is constructed.
# Python 3.5
py> dis.dis("a, b, c = [97, 98, x]")
1 0 LOAD_CONST 0 (97)
3 LOAD_CONST 1 (98)
6 LOAD_NAME 0 (x)
9 ROT_THREE
10 ROT_TWO
11 STORE_NAME 1 (a)
14 STORE_NAME 2 (b)
17 STORE_NAME 3 (c)
20 LOAD_CONST 2 (None)
23 RETURN_VALUE
Before iterators existed, Python had sequence unpacking going back to at
least Python 1.5 if not older, so even if Python used a temporary and
invisible iterator *now* that has not always been the case and it might
not be the case in the future or in alternate interpreters.
Even if Python *sometimes* builds a temporary and invisible iterator, it
doesn't do it all the time, and when it does, it is pure implementation,
not interface. The interpreter is free to do whatever it likes behind
the scenes, but there's no iterator involved in the high-level Python
statement:
a, b, c = [1, 2, 3]
That code involves a list and three assignment targets, that is all.
> This is the same as the behavior for "for"
> loops: if you do "for item in [1, 2, 3]", the actual thing you're
> unrolling is an iterator over the list.
No, the actual thing *I* am unrolling is exactly what I write in my
code, which is the list [1, 2, 3].
I don't care what the Python interpreter iterates over internally, so
long as the results are the same. It can use an iterator, or unroll the
loop at compile-time, or turn it into recursion over a linked list for
all I care.
As much as possible, we should avoid thinking about implementation
details when trying to understand high-level semantics of Python code.
Otherwise, our mental models become obsolete when the implementation
changes.
Or worse, we become incapable of thinking about better implementations
(or better high-level semantics!) because the current implementation is
so entwined with our understanding of the high-level semantics of the
code. If we had allowed the old sequence protocol implementation to take
priority over the abstract, high-level concept of iteration, we wouldn't
have iterators today.
--
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/
