But it's not a big distinction, merely one of intent. And as yet, the person who claimed that wanting an exception from zip was an overwhelmingly common case for them hasn't replied yet to my question - so I may be completely wrong.
Well, hopefully I get more than 2 working hours to reply to these threads! ;)
I suspect that people asking for this feature don't ever imagine catching the exception (or at least, not for any other reason than to terminate the program saying "this should not have happened")...
Honestly, it will likely be a blend of both. Most will be "this should not have happened", but sometimes I actually want it handled at runtime, where I either: - Get the data from my caller, and want to propagate the `ValueError`. - Want to handle differently-sized data as a special case (returning `False`, for example). This is rare, and probably better handled by `zip_longest`. I also don't think that using `zip_longest` is as "obvious" as it seems to many of us. In researching this, I found many cases in the stdlib `ast` module where `zip` is throwing away input that should be raising. And I'm sure I'm not the only one who has used it without setting a `fillvalue`, and forgotten that my iterables could contain `None`.
...so it's more of a "cannot happen" type of check than an exception in the more general sense that something like a ValueError would be intended.
Not sure I agree with this. There's more than one way to look at it of course, but I see this as rejecting malformed input. This is an opportunity for a very simple, lightweight change (only a handful of lines) which gives us a clear usability win. And there's no need to maintain a whole new zip object.