Sure, but I think cases where you want that assumption _checked_ are a lot less common. There are lots of postconditions that you assume just as often as “x, y, and z are fully consumed” and just as rarely want to check, so we don’t need to make it easy to check every possible one of them.
It seems that our experiences differ rather significantly. This isn't a "rare" assumption for me, and it's unique because it's one that `zip` already handles internally.
Of course, the fact that zip() is the shorter form that everyone is used to means that, even if a strict argument is added, few people will bother adding it.
I know that I, and everyone on my team, would use it frequently!
The possible solution is to introduce zip_shortest() with the current behavior of zip(), make zip() emitting a pending deprecation warning when some data is ignored, and after long period of deprecation make it raising an exception if some data is ignored.
Unlike some on this thread, I think the default behavior for `zip` is fine. It's not broken, and it *should* be able to handle infinite iterables by default. This isn't just a "band-aid" fix; it's a feature that allows many (if not most) call sites to check an important assumption that's easy to check inside zip (there's literally logic already handling this case) but heavy to check at every call site.
I'm gonna need someone else to write the implementation.
I'll take care of that. Feel free to reach out to me off list to coordinate. :) Since this has received some degree of support here, I'll go ahead and open a BPO issue. For anyone wondering about semantics, iterator consumption *should* be the same as any old `zip` usage... it seems obvious to me just to raise a ValueError instead of a StopIteration when the option is enabled. If there are arguments against it, lets take it up on BPO!