Incorrect docstring, and Compressor about cramjam HOT 2 CLOSED

Thanks for the note about incorrect docs. 👍

As for Compressors, it depends what you want it for: (forgive me if I explain anything which you're already aware of, this also helps me)

• As implemented, they are only for framed/stream formats. This is because formats like snappy framed or gzip is composed of independently compressed pieces; 'raw/block' in snappy framed and deflate streams for gzip. Both of which will append or prepend additional information to headers and/or footers. Same goes for Lz4. And also why none of the underlying crates implement Read/Write for block/raw formats, as we saw with the discussion in snappy and lz4 missing Read/Write traits in block format

In summary, Compressor maintains the state until complete, then wrapping up any header/foot annotations for these formats.

• Now do you want a Compressor for these block/raw formats to avoid repeated instantiations of underlying encoders/decoders in some hot code path?

This might be worth looking into if this is your aim. I can try to set aside some time to benchmark it a bit to see if exposing some Encoder/Decoder for block/raw formats would be beneficial in such a situation. But it serves a distinctly different purpose than existing Compressors'.

from cramjam.

The hope was to avoid python bytes.join before passing data for compression, but it's a very minor thing. I am surprised, though. It should not require one frame per input to compress a stream (so long as the only flush() is the final one), using some internal buffer. But if the third party library doesn't provide the API, so be it!
Please don't devote any time to this.

from cramjam.