On 17/05/2020 19:43, David Mertz wrote:
On Sun, May 17, 2020 at 2:09 PM Nathan Schneider <neatnate@gmail.com <mailto:neatnate@gmail.com>> wrote:
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. David, you have made this point at great length - we get it. But it seems clear to me (YMMV) that you are in a small minority. And nobody is suggesting changing the default behaviour of zip. Your code won't break. But a lot of users (including you, in a minority of cases) can, *if they choose*, benefit from a 'strict' version. So what is wrong (ceteribus paribus) with making it easy for them to do so?