On Sun, May 17, 2020 at 1:32 PM David Mertz <me...@gnosis.cx> wrote: > On Sun, May 17, 2020 at 12: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). >> > > That's a really terrible analogy. :-( > > I never drive without a seat belt. And a never want the seat belt to > actually matter, of course. Everyone who want a zip_strict behavior > (including me) wants to be able either to catch the exception explicitly or > to have the program fail-fast/fail-hard because of it. > > In contrast, as I've said, more than half of the times that *I* use zip() > it would be BROKEN by using zip_strict() instead (or zip(..., strict=True), > or whichever spelling). Raising an exception for something I want to > succeed, and I want to work exactly as it does (e.g. leave some iterators > unconsumed) is not a "harmless safety precaution". > > 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. > > I have some doors with locks, and some other doors without locks. I have > both for a good reason, but the reasons are different, and depend on > various things like whether a particular room is private or contains > valuables. In truth though, I don't lock my outside doors because I live > in a community of "consenting adults" (occasionally I do lock the bathroom > door for privacy, for a short while... no-locks is definitely strongly my > default mode, as is no-strict when I zip). > >
Good, I think we're getting to the crux of the usability debate. 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?) As long as we are not changing the default behavior of zip(), I don't anticipate a ton of users using strict-zip unthinkingly—I would guess the risk of uncaught bugs with the status quo is much, much higher. Is there a precedent where a new non-default option was introduced and incorrect use of it became widespread? Nathan
_______________________________________________ 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/ATK5DP3YP7ZL55C2Z3I2J5ND2JZFJ6RE/ Code of Conduct: http://python.org/psf/codeofconduct/
