Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
I don't think this is needed in the builtin zip at all. I think that there is no consensus on Python-Ideas that this is needed or desirable. I especially don't think the API should be a keyword flag on zip. Flag arguments which change the behaviour of functions are at best a code-smell and at worst an outright anti-pattern. It is not always practical to avoid them, but in this case it certainly is: if we need this (I'm not sure we do) then a separate zip_strict() function in itertools next to zip_longest() is better than a flag on the builtin zip. (That's not to say that the zip_strict iterator must be an independent class to the builtin zip and itertools.zip_longest, they can share a common backend. It is the public API I am referring to.) I've already posted an implementation on the mailing list, it is about half a dozen or so lines of Python. Another independent implementation is available from the current development branch of more-itertools, more or less the same only with a less informative error message. Personally, the fact that this has only just hit more-itertools counts as a point against this function to me: more-itertools is the "everything including the kitchen sink" grab-bag of iterator tools, and even they didn't think they needed "zip_equal" until version literally a few days ago. It's so new it isn't even documented yet: https://pypi.org/project/more-itertools/ ---------- nosy: +steven.daprano _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40353> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
