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

2011-02-19 Thread Greg Kochanski
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

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

2011-02-19 Thread Greg Kochanski
Changes by Greg Kochanski : -- resolution: invalid -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue11248> ___ ___ Python-bugs-

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

2011-02-19 Thread Greg Kochanski
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 progra

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

2011-02-19 Thread Greg Kochanski
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 st

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

2011-02-19 Thread Greg Kochanski
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

[issue2295] cPickle corner case - docs or bug?

2008-03-15 Thread Greg Kochanski
New submission from Greg Kochanski <[EMAIL PROTECTED]>: If you attempt to cPickle a class, cPickle checks that it can get the identical class by importing it. If that check fails, it reports: Traceback (most recent call last): ... "/usr/local/lib/python2.5/site-packages/newstem2-0

[issue2294] Bug in Pickle protocol involving __setstate__

2008-03-15 Thread Greg Kochanski
New submission from Greg Kochanski <[EMAIL PROTECTED]>: If we have a hierarchy of classes, and we use __getstate__/__setstate__, the wrong class' __setstate__ gets called. Possibly, this is a documentation problem, but here goes: Take two classes, A and B, where B is the child of A.