On Mon, 27 Apr 2020 13:39:19 -0700 Christopher Barker <python...@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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/CFTJLXF2K35HZURE4BB5NL6KMMBBARBM/ Code of Conduct: http://python.org/psf/codeofconduct/
