> 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. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JQ2SONICZ7NDDYR27NFSBFMW26L56IPK/ Code of Conduct: http://python.org/psf/codeofconduct/
