On Sun, May 17, 2020 at 6:22 PM Nathan Schneider
Let me attempt a metaphor, which won't be perfect but may help:
The safety one gets from strictness is a bit like driving a car wearing a seat belt. It is not fundamentally different from driving a car without a seat belt, and in most cases you hope the seat belt will not come into play. But it is a precaution that is worth taking in *most* circumstances (not all, e.g. for infants a standard seat belt won't work).
The built-in approaches (whether spelled as zip(strict=True), or zip.strict(), or a new zip_strict() builtin) make it really easy for everybody to take the safety precaution where it is appropriate. By contrast, putting it in itertools where it has to be imported is like requiring someone to rent seat belts in order to use them in their car. Some safety-conscious folks will go to the trouble; others won't.
itertools.zip_longest() is sort of a power tool for specialized situations—in our analogy, say, a pickup truck that has to be rented. Yes, with some work it *can* be used to emulate strict-zip, but most people won't think of it that way; they will think of it as something you only need in special situations.
Thanks Nathan, I think this is the right idea. To make it a bit less metaphorical, strict zip is essentially an assertion. The language doesn't need assert statements - instead of ``` assert cond, message ``` we could just write [1]: ``` if __debug__ and not cond: raise AssertionError(message) ``` or import an `assert` function and write: ``` __debug__ and assert(cond, message) ``` But it's good that we have the assert statement, because it makes it easy to write safe code and so people are encouraged to do so. Similarly, you can write code without writing tests. Often that's really tempting and writing tests feels a bit pointless. It may be obvious that the code works, and the tests won't reveal anything at the time. But even then it's helpful when someone later makes a breaking change and are alerted immediately. So we need frameworks to make testing as easy as possible so we can fight the temptation to not write tests. The Python community has taken this as far as pytest's AST magic just to be able to write `assert x == y` instead of `self.assertEqual(x, y)`. A strict zip often won't provide any benefit when it's written, as it's 'obvious' that the lengths involved are equal, but just like tests it can prevent regressions. ------ [1] Assuming that the compiler optimises away the statement entirely when `__debug__` is False. Right now it seems that CPython can optimise away `if __debug__:` and `if False:` but not `if __debug__ and True:` even though it collapses the condition to a constant False which it immediately tests for: ``` from dis import dis def foo(): if __debug__ or True: print(3) dis(foo) 5 0 LOAD_CONST 1 (False) 2 POP_JUMP_IF_TRUE 4 6 >> 4 LOAD_GLOBAL 0 (print) 6 LOAD_CONST 3 (3) 8 CALL_FUNCTION 1 10 POP_TOP 12 LOAD_CONST 0 (None) 14 RETURN_VALUE ```