I have no objection to adding a zip_strict() or zip_exact() to itertools. I am used to the current behavior, and am apparently in minority in not usually assuming common length iterators. Say +0 on a new function.
I'd say I'm +0 also -- I don't think it'll get used much.
But I'm definitely -1 on adding a mode switch to the built-in. This is not the way Python is usually done. zip_longest() is a clear example,
Yes, indeed. But there is a difference here. If you want zip_longest capability, your code simply can not work with zip(). So folks will make the effort to go import it from itertools.
But most code that could benefit from "strict" behavior will run fine with zip() -- just with less safely, or making a safety check separately. So I don't think a function in itertools would get used much
Granted, that doesn't say anything about the API consistency (or lack thereof) of adding a "mode flag" -- if that's important, then, well, I guess it's not an option. Are there really no mode flags in Python? (I do recall a quote attributed to Guido about not using a two-mnode flag, when another function will do).
but so is the recent cut_suffix (or whatever final spelling was chosen). Some folks wanted a mode switch on .rstrip(), and that was appropriately rejected.
In my mind that was more about consistency with the rest of the string API than about a global "that's not how we do things in Python" -- but It may have been both.
- CHB
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython