Or at least, make it use this by default. The reason being that ByExtension() supports many more formats.

ZSTD expanded their range of compression levels to include negative integers. The current "max" (-5) pushes it into LZ4 territory. I would make a pull request, but I'm not sure how many additional levels you want to test by default.

It should be quite obvious for first time users to see some simplest APIs (to compress/uncompress buffer without dealing with any file io). Strangely, lizard has links to file format, but no clues to basic api use (is it in examples, which one is the "hello world"?. I've been using zlib for more than a decade, and I've never needed to know its file format, perhaps same for 90% of its users.

IMO

Your default levels for ZSTD seem a little wonky:

• TURBO: ZSTD is missing, it should be -5 | --fast=5 (the fastest level currently available). This should push it into LZ4 territory.
• EFFICIENT should probably include 3, ZSTD's default level.
• OPTIMAL (meaning best trade off?) should probably be 20, as 22 balloons memory usa

Documentation says that Compressor.flush emits all remaining data, but in fact it does not.
This fails

bc = brotli.Compressor()
assert bc.compress(b'Time to Relax!') + bc.flush() == brotli.compress(b'Time to Relax!')

This passes

bc = brotli.Compressor()
assert bc.compress(b'Time to Relax!') + bc.finish() == brotli.compress(b'Time to Relax!')

Documentation could use some work. For Java it obviously doesn't work as described.

Also would be great to get support for buffered streams.

Good work so far!

The time and effort you put to complete the documentation was really helpful :)
without it we were unable to run it this fast and easy and you had answer for all the problem we faced :)

That was great (at the end out manager decided to go with Microsoft release because as the thing you can guess)

but without your documentation it was not possible to get it run.

Keep it up bro, we really