On Sun, May 17, 2020 at 6:22 PM Nathan Schneider <neatn...@gmail.com> wrote:
> 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
```
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/IU4C7Z6HFZQKXEAG7PNBDFKORA5JWEAG/
Code of Conduct: http://python.org/psf/codeofconduct/
