The more I read the discussion, the more zip_strict() feels like an anti-pattern to me.

I've used zip_longest occasionally, but never really hit a need for zip_strict() ... which obviously I could have written in a few lines if I wanted it.

Since I never know how many elements an iterator has let—including perhaps infinity—any such function has to be leap-before-you-look.  But the effect is that is that I wind up consuming more than I want of some iterators.  Let's sayI have this code:

>>> it1 = iter([1,2,3])
>>> it2 = iter([4,5])
>>> it3 = iter([6,7,8, 9])
>>> list(zip(it1, it2, it3))
[(1, 4, 6), (2, 5, 7)]
>>> next(it3)
8

That seems fine.  If I had used zip_longest() I could get some extra tuples, and indeed I'd have to check whether there were sentinel values inside of them.  Depending on what I was doing, the non-sentinels might still be useful for my processing though. But this hypothetical zip_strict() (or I guess actual very recently in itertools, but I haven't checked the semantics) would raise an exception of some kind instead.

It's not easier to check for an exception than it is for a sentinel, so that really don't get us anything at all in terms of saving code or clarity.  If anything, the check-for-sentinel feels slightly cleaner to me.

But worse is that most versions being discussed here seem to consume the 8 from it3 before raising the exception (perhaps sticking it in the exception object).  I guess if it's stashed in the exception object it's not entirely lost.  Still, in my code it3 remains a perfectly good iterator that I can keep around to pull more values from.  Under the zip_strict approach, I have to dig a value out of the exception object before proceeding on normal iteration of it3 later in my code.  That just feels awkward to me.  Not un-doable, but certainly not easier.