On Wed, Apr 22, 2020 at 12:23 PM David Mertz <mertz@gnosis.cx> wrote:

On Wed, Apr 22, 2020, 4:24 AM Antoine Pitrou
But, as far as I'm concerned, the number of times where I took advantage of zip()'s current acceptance of heteregenously-sized inputs is extremely small. In most of my uses of zip(), a size difference would have been a logic error that deserves noticing and fixing.

Your experience is very different from mine.

I'm in Antoine's camp on this one. A lot of our work is data analysis, where we get for example simulation results as X, Y, Z components then zip them up into coordinate triples, so any mismatch is a bug. Having zip_equal as a first-class function would replace zip in easily 90% of our use cases, but it needs to be fast as we often do this sort of thing in an inner loop...