On Apr 24, 2020, at 11:07, Brandt Bucher <brandtbucher@gmail.com> wrote:
1. Likely the most common case, for me, is when I have some data and want to iterate over both it and a calculated pairing:
x = ["a", "b", "c", "d"] y = iter_apply_some_transformation(x) for a, b in zip(x, y): ... ... # Do something. ...
Your other examples are a lot more compelling. I can easily imagine actually being bitten by zip(*ragged_iterables_that_I_thought_were_rectangular) and having a hard time debugging that, and the other one is an actual bug in actual code, which is even harder to dismiss. I think this one, on the other hand, is exactly what I think doubters are imagining. I can easily imagine cases where you want to zip together two obviously-equal iterables, but when they’re obviously equal, adding a check for that is hardly the first thing I’d think about defending against. (For example, things like using “spam eggs cheese”.strip() instead of .split() as the input are more common logic errors and even less fun to debug…) And that’s why people keep asking for examples—because the proponents of the change keep talking as if there are examples like your 2 and 3 where everyone would agree that there’s a significant benefit to making it easier to be defensive, but the wary conservatives are only imagining examples like your 1. Anyway, if I’m right, I think you just solved that problem, and now everyone can stop talking past each other. (Although the couple of people who suggested wanting to _handle_ the error as a normal case rather than treating it as a logic error to debug like your examples still need to give use cases if they want anything different than what you want.)