[issue11248] Tails of generator get lost under zip()

Raymond Hettinger added the comment: I've looked at the docs again and think they're fine. And in the 3.x docs, the iterator version of zip() specifies its implementation with a pure python equivalent that makes it clear that the iterator is not run to exhaustion. Note that zip() has exist

[issue11248] Tails of generator get lost under zip()

Greg Kochanski added the comment: The code (bug312.py) was not submitted as a "pattern", but rather as an example of a trap into which it is easy to fall, at least for the 99% of programmers who are users of the language rather than its implementers. The basic difference is that while one

[issue11248] Tails of generator get lost under zip()

Raymond Hettinger added the comment: This is not a bug. It is an implementation specific detail and is not guaranteed behavior. The submitted "example bug" is horrible code that makes unwarranted assumptions about the implementation -- it is an anti-pattern to write generators that assume t

[issue11248] Tails of generator get lost under zip()

Changes by Daniel Urban : -- nosy: +durban ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue11248] Tails of generator get lost under zip()

Changes by Georg Brandl : -- assignee: -> docs@python components: +Documentation -None nosy: +docs@python stage: committed/rejected -> needs patch ___ Python tracker ___ ___

[issue11248] Tails of generator get lost under zip()

Changes by Greg Kochanski : -- resolution: invalid -> status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue11248] Tails of generator get lost under zip()

Greg Kochanski added the comment: Yes, the current behaviour makes sense from a language designer's viewpoint, and maybe even from the user's viewpoint (if the user thinks about it a carefully). But, that's not the point of a computer language. The whole reason we program in languages like

[issue11248] Tails of generator get lost under zip()

Ezio Melotti added the comment: a) that's true, even if the behavior makes sense (when the first generator ends there's no reason to see what's next in the second). Georg, do you think it should be documented? b) if you want to be sure that some clean-up is executed you should use a try/fina

[issue11248] Tails of generator get lost under zip()

Greg Kochanski added the comment: (a) It is not documented for the symmetric (4, 4) case where the two generators are of equal length. (b) Even for the asymmetric case, it is not documented in such a way that people are likely to see the implications. (c) Documented or not, it's still a wart

[issue11248] Tails of generator get lost under zip()

Ezio Melotti added the comment: This behavior is documented[0]: """The returned list is truncated in length to the length of the shortest argument sequence.""" You can use izip_longest instead[1]. [0]: http://docs.python.org/library/functions.html#zip [1]: http://docs.python.org/library/itert

[issue11248] Tails of generator get lost under zip()

New submission from Greg Kochanski : When you have a generator as an argument to zip(), code after the last yield statement may not get executed. The problem is that zip() stops after it gets _one_ exception, i.e. when just one of the generators has finished. As a result, if there were any im