Nadeem Vawda <nadeem.va...@gmail.com> added the comment: > False alarm; go ahead with the review. I took a look too early in the > morning before caffeine kicked in.
No worries. I know the feeling. The tests look fine. The bodies of testRead() and testReadMultiStream() appear to have been swapped, though. I'm guessing testRead() was supposed to remain unmodified, with testReadMultiStream() testing the case of streams=5? For the change to BZ2File._fill_buffer(), I'm not sure that the check for end-of-file is correct. It seems that if the end of rawblock lines up with the end of a stream, the mode will be set to EOF even if there are more streams waiting to be read. Is this possible? > A note on bz2 behavior: A BZ2Decompressor object is only good for one > stream; after that eof is set and it will refuse to continue to the > next stream; this seems in line with bzip2 manual I think this is the right way to do things. BZ2Decompressor is a low- level wrapper around the underlying C API -- it should not grow extra features unnecessarily. Also, certain use-cases might depend on being able to detect the end of a logical stream; this would not be possible if BZ2Decompressor were to be changed. The difference in behaviour from BZ2File and decompress() should probably be documented, though. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1625> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
