On Sat, 2 May 2020 at 12:19, Steven D'Aprano <steve@pearwood.info> wrote:
- Is there a need for it? Granted. - Is it complicated to get right? No.
This one, I'll query. Until someone (probably you) mentioned it, I didn't think of using zip_longest to do this - probably because I was locked into thinking about the *shortest* element, and "abort when I run out".
- Is performance critical enough that it has to be written in C? Probably not. - Is there agreement on the functionality? Somewhat. - Could that need be met by your own personal toolbox? - or a recipe in itertools?
This, I think, would be a good idea. It would be discoverable (name it zip_strict), and would offer a standard, robust implementation. If (and this is a big if) it becomes sufficiently popular, a proposal to "promote" it from a recipe to an actual member of itertools would make sense.
- or by a third-party library? - or a function in itertools?
We've heard from people who say that they would like a strict version of zip which raises on unequal inputs. How many of them like this enough to add a six line function to their code?
My personal opinion is that given that Brandt has found one concrete use for this in the stdlib, it is probably justifiable to add it to itertools. Whether it even needs a C accelerated version, or just a pure Python version, I don't care, but then I'm not doing the work :-)
I'm not sure the evidence warrants an itertools function yet, but that's largely something for Raymond Hettinger (as the module maintainer) to take a view on. (I'd hope Raymond would also weigh in on the PEP as it stands, too, given that it's so closely related to itertools). Paul