I don't think this is needed in the builtin zip at all. I think that there is no consensus on Python-Ideas that this is needed or desirable.

I especially don't think the API should be a keyword flag on zip. Flag arguments which change the behaviour of functions are at best a code-smell and at worst an outright anti-pattern.

It is not always practical to avoid them, but in this case it certainly is: if we need this (I'm not sure we do) then a separate zip_strict() function in itertools next to zip_longest() is better than a flag on the builtin zip.

(That's not to say that the zip_strict iterator must be an independent class to the builtin zip and itertools.zip_longest, they can share a common backend. It is the public API I am referring to.)

I've already posted an implementation on the mailing list, it is about half a dozen or so lines of Python. Another independent implementation is available from the current development branch of more-itertools, more or less the same only with a less informative error message.

Personally, the fact that this has only just hit more-itertools counts as a point against this function to me: more-itertools is the "everything including the kitchen sink" grab-bag of iterator tools, and even they didn't think they needed "zip_equal" until version literally a few days ago. It's so new it isn't even documented yet:

https://pypi.org/project/more-itertools/