If you want a better metaphor: Some door handles include locks, others do not. "Strict" ones have locks. So yes, it's possible to leave the lock in the unlocked position, and then it functions pretty much the same as one without a lock. But likewise, it's possible to leave the door in the locked position when you don't have the key on you, and you face a significant inconvenience that serves no purpose.
For some of us, strictness is a property that users often want when they use zip(), whether they are properly enforcing it or not—so giving them a really easy way to opt into it would help avoid bugs. (Personally, I cannot remember the last time I actually wanted non-strict zip.)
I think David is saying that he more often wants non-strict zip, and it would be tempting and dangerous to make strict-zip too easy to use for those who aren't thinking carefully about their code, so it would be better to bury strict-zip in itertools for the power users who really know they need it. (Is that a fair summary?)
The API matter is really orthogonal to this. My point here is that Nathan and some other discussants are operating under the assumption that: "Everyone really wants strict-zip but they just haven't had a way to express it conveniently. They all assume their iterables are the same length already, so this just adds a check."
I disagree strongly with that assumption. I think that the actual majority of my uses of zip are non-strict. Admittedly, I have not scanned my code to count that; for that matter, most of the code I have written is no longer accessible to me, being written for companies I no longer work for (and not open source). But whatever the actual percentages might be, I COMMONLY want a non-strict zip by actual specific intention, not because I've made a wrong assumption about the nature of the iteratables I use. Of course, I also commonly use zip with the implicit assumption that my iterables are the same length... I have most certainly written many lines where I would appropriately choose strict-zip if it existed (whichever API).
To me, itertools is not some hidden vault only accessible after performing Herculean labors. I believe boolean mode switches are usually a bad design for Python. Not always, there are exceptions like open(). And I think Guido made the good point that one of the things that makes mode switches bad is when they change the return type, which the `strict=True` API would not do (but it would create a new kind of exception to worry about).
In fact, itertools is pretty much the only module where I occasionally write `from itertools import *`. There are many good things in that module that are general purpose. But namespaces, after all, are a honkin' good idea. I think if `zip()` were proposed today as a brand new function that hadn't existed, I would advocate strongly for putting it inside itertools. Probably `map()` and `filter()` similarly. So I don't want zip_strict() to join built-ins, but it's not because I think it is a niche case, but rather because I think we already have more in built-ins than we should, and some of it could very reasonably live in a more descriptive namespace. I would certainly not mind if we added `zip_shortest()` as a synonym for the current zip to itertools.
The dead increasingly dominate and strangle both the living and the
not-yet born. Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.