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.
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, 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.
Python uses such an approach (separate functions) because there are real flaws in the mode switching approach? Or just historically? As for me the mode switching approach in the current situation looks reasonable, because the question is how boundary conditions should be treated. I still prefer three cases switch like `zip(..., mode=('equal' | 'shortest' | 'longest'))`... but also ok with `strict=True` variant.
Also I don't think that comparison with .rstrip() discussion is fair - because in that case, it was proposed to switch
two completely different approaches (to treat as string vs to treat as set of chars) which is too much for just a switch thorugh argument. While in zip case it is just how boundaries are treated.
If zip_strict() is genuinely what you want to do, an import from stdlib is not much effort to get it. My belief is that usually people who think they want this actually want zip_longest(), but that's up to them.
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/DZZ7I3PEVYB2LW6Y2ECSQRUUTYEB3D7O/
Code of Conduct: http://python.org/psf/codeofconduct/