On Apr 20, 2020, at 13:49, Ram Rachum <ram@rachum.com> wrote:
Good point. It would have to be dependent on position. In other words, you would never pass an iterator into zip with any expectation that it would be in a usable condition by the time it's done.
Actually, I can't think of any current scenario in which someone would want to do this, with the existing zip logic.
Admittedly, such cases are almost surely not that common, but I actually have some line-numbering code that did something like this (simplified a bit from real code): yield from enumerate(itertools.chain(headers, [''], body, ['']) … but then I needed to know how many lines I yielded, and there’s no way to get that from enumerate, so instead I had to do this: counter = itertools.count() yield from zip(counter, itertools.chain(headers, [''], body, ['']) lines = next(counter) (Actually, at the same time I did that, I also needed to add some conditional bits to the chain, and it got way too messy for one line, so I ended up rewriting it as a sequence of separate `yield from zip(counter, things)` statements. But that’s just a more complicated demonstration of the same idea.) But again, this probably isn’t very common. And also, while you were asking about the existing zip logic, the more important question is the new logic you’re proposing. I can’t imagine a case where you’d want to check for non-empty and _then_ use it, which is what’s relevant here. There probably are such cases, but if so, they’re even rarer, enough so that the fact that you have to wrap something in itertools.tee or more_itertools.peekable to pull it off (or just not use the new strict=True/zip_strict/zip_equal) is probably not a great tragedy.