The zip iterator documentation says: "The zip iterator provides the ability to parallel-iterate over several controlled sequences simultaneously. ... Moving the zip iterator moves all the iterators in parallel."
What is not specified is what happens when the several different sequences are of unequal size. At the moment, everything just blows up. This behavior is consistent with the STL's algorithms. std::equal, for example, only accepts a single iterator for the second container. The
Leo Goodstadt wrote: programmer must ensure that the second container has at least as many items in it from the position of the supplied iterator as exist between the iterator range supplied for the first container. The std::back_insert_iterator, std::front_insert_iterator, and std::insert_iterator adaptors exist so that the transformational STL algorithms can be utilized without having to initialize the receiving container with dummy items in advance.
python zip, if I remember correctly, just stops at the end of the shortest sequence in the tuple. (python map works differently). This seems a sensible thing to do.
Python iterators are different animals than STL iterators; Python's zip() probably just halts on a StopIteration exception raised by one or more of the iterators from the sequences passed into it. There is no exception raised when an STL iterator reaches the past-the-end point of the container it was generated by.