Ian Kelly wrote: > On Mon, Mar 14, 2016 at 9:06 AM, Oscar Benjamin > <oscar.j.benja...@gmail.com> wrote: >> On 14 March 2016 at 14:35, Rick Johnson <rantingrickjohn...@gmail.com> >> wrote: >>> >>> I would strongly warn anyone against using the zip function >>> unless >> ... >>> I meant to say: absolutely, one hundred percent *SURE*, that >>> both sequences are of the same length, or, absolutely one >>> hundred percent *SURE*, that dropping values is not going to >>> matter. For that reason, i avoid the zip function like the >>> plague. I would much rather get an index error, than let an >>> error pass silently. >> >> I also think it's unfortunate that zip silently discards items. Almost >> always when I use zip I would prefer to see an error when the two >> iterables are not of the same length. > > It's sometimes very useful, though. For example on multiple occasions > I've taken advantage of the fact that enumerate(x) is equivalent to > zip(itertools.count(), x). If zip raised an error then that would only > be possible using islice, and then only if the length is known in > advance. > > Also, in order for zip to know that the lengths are not equal, it > would have to try to read one additional item from the longer > iterable. That's rather unfortunate if it's an iterator and you're > hoping to catch the exception and then use the rest of the iterator > for something else.
That's a problem you may run into with the current zip(), too -- unless you know that the first is the shortest iterator: >>> from itertools import count >>> indices = count() >>> for items in "abc", "def", "gh": ... list(zip(indices, items)) ... [(0, 'a'), (1, 'b'), (2, 'c')] [(4, 'd'), (5, 'e'), (6, 'f')] [(8, 'g'), (9, 'h')] I'm with Oscar here, raising an exception would be the better default; the current implementation could have been made available as itertools.zip_shortest(). -- https://mail.python.org/mailman/listinfo/python-list
