On Apr 20, 2020, at 11:25, Brandt Bucher <brandtbuc...@gmail.com> wrote: > > I disagree. In my own personal experience, ~80% of the time when I use `zip` > there is an assumption that all of the iterables are the same length.
Sure, but I think cases where you want that assumption _checked_ are a lot less common. There are lots of postconditions that you assume just as often as “x, y, and z are fully consumed” and just as rarely want to check, so we don’t need to make it easy to check every possible one of them. As I said, wanting to check does come up sometimes—I know I have written this myself at least once, and I’d be a little surprised if it’s not in more-itertools. But often enough to be a (flag on a) builtin? I’ve also written a zip that uses the length of the first rather than the shortest or longest, and a zip that skips rather than filling past the end of short inputs, and there are probably other variations that come up occasionally. But if they don’t come up that often, and are easy to write yourself, is there really a problem that needs to be fixed? And even if checking is the most common option after the default, it seems like a weird API to have some options for what to do at the end as keyword parameter flags and other options as entirely separate functions. Maybe a flag for longest (or a single at_end parameter with an enum of different end-behaviors truncate, check, fill, skip where the signature can immediately show you that the default is truncate) would be a better design if you were doing Python from scratch, but I think the established existence of zip_longest pushes us the other way. _______________________________________________ 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/BNBKATJM4NDXUG53WRZFSO7VWRWDCA5B/ Code of Conduct: http://python.org/psf/codeofconduct/
