On May 5, 2013, at 23:54 , Lindsey Kuper <[email protected]> wrote: > On Sun, May 5, 2013 at 4:19 PM, Noam Yorav-Raphael <[email protected]> wrote: >> I have a simple suggestion: the current implementation of zip() returns an >> iterator which stops whenever one of the two iterators it gets stop. >> I use zip() in python quite a bit. I always have a few lists, where the i'th >> value in each corresponds to the same thing. I use zip in python to iterate >> over a few of those lists in parallel. >> >> I think this is the usual use case. In this use case, when the two lists >> have a different length it means that I have a bug. it seems to me that >> Python's behavior, and current Rust behavior, is contrary to "Errors should >> never pass silently" from the zen of Python. >> >> What do you think of changing this, so that zip() will fail in such a case? >> Another iterator, say, "zipcut" can implement the current behavior if >> needed. > > For what it's worth, in Wikipedia's comparison of implementations of > zip for various languages [0], none of them raise an error when the > lists are different lengths; they all either stop with the shorter of > the two lists, or fill in the missing values with a nil value.
That may be coincidence, however, since the page lists only a handful of languages. As a counter example, OCaml, which calls it 'combine', throws. Standard ML even provides two variants, 'zip' and 'zipEq', the latter throwing. (And as an additional data point, nowhere in my SML code have I ever had a need for the non-throwing version.) /Andreas _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
