On Mon, 27 Apr 2020 13:39:19 -0700 Christopher Barker <pythonchb@gmail.com> wrote:
There is one "downside" to this in that it potentially leaves the iterators passed in in a undetermined state -- partially exhausted, and with a longer one having had one more item removed than was used. But that exists with "zip_shortest" behavior anyway. But it would be a minor reason to do the concertizing approach -- at least then you'd know your iterators were fully exhausted.
SIDE NOTE: this is reminding me that there have been calls in the past for an optional __len__ protocol for iterators that are not proper sequences, but DO know their length -- maybe one more place to use that if it existed.
The C standard library has an ungetc function that, well, "ungets" one character from the end of a character stream. The next time the stream is read, it returns that ungotten character first, and then goes back to the stream. Such a feature could solve this problem on infinite streams without having to concretize them. (Unless, of course, zip's *caller* tried to unget an element of the iterator immediately after zip did, but that's no a likely occurrance.) Dan -- “Atoms are not things.” – Werner Heisenberg Dan Sommers, http://www.tombstonezero.net/dan