> 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.