David Mertz writes:
If zip_strict() is genuinely what you want to do, an import from stdlib is not much effort to get it.
+1. I'm definitely in the camp wanting this to be a new function.
My belief is that usually people who think they want this actually want zip_longest(), but that's up to them.
I don't see how that would be true, to be honest. "zip" implies that the data in the streams are in fact synchronized. Any difference in lengths implies that the synchronization is lost "somewhere". In general, there's no way of knowing where the data generating process broke down so they have to throw away the whole computation. I would guess that in a quite large set of cases, desynchronization implies a logic error somewhere, so they have to fix the algorithm. Of course there are cases where zip is used to *create* the synchronization, such as zip(tasks, volunteers) or zip(shuffled(cards), players), but in those cases zip_longest rarely makes sense to me. In fact you probably want a "circular" zip_longest, where you keep "dealing", starting over at the beginning of an iterable whenever it is exhausted until all the tasks, volunteers, or cards have been dealt. Or you just want zip, as in a case like zip(rooms, students), and you deal with the remainder(s) of the longer iterable(s) in a separate process. So it seems to me that zip_shortest, zip_strict, and zip_longest all have valid use cases, and it's clear they don't exhaust all the cases of zipping. It's unclear to me which is the most common case, but I think the folks who want a zip_strict have a good case for a function in the stdlib, though I see no need to change the builtin.