You’re right, it did sound like that, and I don’t mean that. Sorry.

zip.strict has _some_ of the same problems as zip(strict=True), but definitely not _all_ of them. And I definitely prefer zip.strict to the flag.

At the time I wrote this (I don’t know why it took a few days to get delivered…), zip.strict had come up the first time and been roundly shouted down, and it seemed like.nobody but me (and the proposer, of course) had found it at all acceptable, and I was trying to make the point that if people don’t like zip.strict, the same things and more apply to passing an always-constant flag, so it should be even more acceptable.

Then. over the last few days, a bunch of people came around on zip.strict. And that seems to be at least in part because people came up with better arguments than the first time around. (For example, I forget who it was that pointed out that you don’t really have to start thinking of zip as a class and zip.strict as an alternate constructor, because plenty of people don’t realize that’s true for chain.from_iterable and they still have no more problem using it than they do for datetime.now.)

So now, rather than it being a +0 for me and a distant second choice behind an itertools function, I think I’m pretty close to evenly torn between the two.

I do think that if we add zip.strict, we should also probably add zip.longest, not just think about maybe adding it some day. And it might even be worth adding zip.shortest, even if we have no intention of ever eliminating zip() itself or changing it to mean zip.strict. But I don’t have good arguments for these; I’ll have to think about it a bit more to explain why I think consistency easily trumps the costs for this variant of the proposal but probably fails for other variants.