为什么`zip`从第一个迭代器中又吃掉一个元素？

Question

I'm studying Item 76 in Effective Python (2nd Ed.), and I run into a case that I don't understand. Specifically, I don't understand why zip consumes one additional element of its first argument. Consider the following code:

l1 = []
l2 = [1]
l1_it = iter(l1)
l2_it = iter(l2)
test_it = zip(l2_it, l1_it)
_ = list(test_it):

try:
    next(l2_it)
except StopIteration:
    print('This should not happen')

This actually prints This should not happen , and I find this very surprising. I would expect zip to leave its first argument in a state where there is still one element to be retrieved. And the fact is that if I use zip(l1_it, l2_it) (that is, the shortest list is first), then indeed I can call next(l2_it) without triggering an exception.

Is this expected?

Answer 1

zip takes the length of the shortest iterable and limits to that. Since l1 has no items, the item in l2 will not be processed.

However... with an iterable Python doesn't know how many items are available so its only recourse is to try and fetch an item. If there is no item it gets an exception. If there is an item, it has already consumed it from the iterator by now.

Perhaps you were expecting the behaviour of zip_longest? https://docs.python.org/3/library/itertools.html?highlight=itertools#itertools.zip_longest

To illustrate the iter() behaviour:

>>> x = [1]
>>> x_iter = iter(x)

# We cannot get the length and unless we are prepared to fetch it,
# we cannot check if there are items available.
>>> len(x_iter)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object of type 'list_iterator' has no len()

# First item can be fetched
>>> next(x_iter)
1

# There is no second item so Python raises a StopIteration
>>> next(x_iter)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration

Answer 2

I had exactly this problem and after reading this and answers i understood, why this happens and simply changed the order of zipped iterables. The one that ends before the other (the shorter iterable) first and then the one where should not be "eaten" from an (on the first view) 'unexpected' additional element" as second and the problem is solved.

So basically as conclusion in my opinion one should remember always to put shorter iterable as first and longer iterable as second argument for zip to avoid "surprises".

fe to use similar as your example:

>>> l1 = [1]                      # the shorter one for left side
>>> l2 = [2, 3]                   # the longer one for right side
>>> l1_it = iter (l1)
>>> l2_it = iter (l2)
>>> test_it = zip (l1_it, l2_it)  # zip now has stop iteration
                                  # from l1_it and leaves l2_it
                                  # untouched further
>>> print (list (test_it))        # go through test_it with list
[(1, 2)]                          # and print it

>>> next (l2_it)                  # as you can see here there is
3                                 # still a next (now as expected)