Remove `EndlessZstdDecompressor`?

[emmatyping]

EndlessZstdDecompressor is rather different from other stdlib APIs. It doesn't stop at a single frame, and is more similar to the behavior of decompress().

It probably should be removed?

[Rogdham]

In zstdandard, the spec states that compressed data is made of one or several frames.

The right comparison is xz, whose spec states that compressed data is made of one of several streams.

In the stdlib, we have lzma.LZMADecompressor(format=lzma.FORMAT_XZ) already.

[Rogdham]

Trying to look at the global picture in the below.

Here are some decompression use cases that I think needs to be supported:

1. Decompressing everything at once
2. Decompressing data as needed (streaming)
3. Stopping at the first frame (advanced use-cases)

Point 1 is answered by decompress(), and point 3 by ZstdDecompressor.

For point 2, I can see 3 possibilities:

• Use EndlessZstdDecompressor
• Recreate EndlessZstdDecompressor by chaining ZstdDecompressors manually
• Use ZstdFile (by transforming the data to be decompressed into a file-like object)

If we remove EndlessZstdDecompressor, advanced users knowing about internals of zstd format will probably recreate it with ZstdDecompressors, other users will probably failback to ZstdFile.

I personally don't have a strong opinion either way, so I'm just giving some pointers in hope it helps others.

[emmatyping]

I was also thinking in terms of those three use cases, great minds think alike :)

I think it isn't going to be that uncommon to have a series of frames that you want to read incrementally. But I also expect most of those use cases to happen with file like objects, which makes me think ZstdFile should be used. The underlying _compression stream abstractions used by all of the *File classes re-uses a normal *Decompressor object to handle multiple streams/frames.

[emmatyping]

Implemented in 99a4491