Decide on and document zstd options

[emmatyping]

The current module uses three IntEnums to define options for Zstandard. https://github.com/emmatyping/cpython/blob/zstd/Lib/compression/zstd/__init__.py#L184-L246

Should the API be kept as CParameter/DParameter? Should those be converted into constants on the module?

Regardless of what method is chosen, it needs to be documented.

[Rogdham]

I would be slightly in favor of converting into constants on the module, solely because this is what existing modules (e.g. lzma) are doing already.

[emmatyping]

One issue with using constants on a module is if someone uses compressionLevel in place of windowLogMax when passed to the decompressor, that won't be caught. They are both C enum variants with value 100. For that reason I am leaning towards keeping CParameter/DParameter.

One possible workaround would be wrapping the constants in zstd with newtypes, i.e.

class CParameter(int):
    """Newtype to mark a value as a compression parameter"""

compressionLevel = CParameter(compressionLevel)
...

Then the module state would keep the CParameter/DParameter types, and use that to check compression vs decompression parameters.

FWIW at this point I think it would be better to keep things as they are and maybe export the CParameter attributes at the module level, e.g.

# in compression.zstd module

compressionLevel = CParameter.compressionLevel

That makes the API simpler to use but keeps the existing known working code :)