Decide on and document zstd options #5

Activity

1. emmatyping

   added

   enhancement

   help wanted

   zstdFor issues related to Zstandard in CPythonFor issues related to Zstandard in CPython

   question

   and removed

   help wanted

   on Apr 9, 2025
2. Rogdham commented on Apr 18, 2025

   

   Rogdham

   on Apr 18, 2025

   More actions

   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.

   👍React with 👍1Reacted by Emma Smith
3. emmatyping commented on Apr 24, 2025

   

   emmatyping

   on Apr 24, 2025

   Last edited by emmatyping

   OwnerAuthor

   More actions

   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 :)
4. emmatyping

   closed this as completedon Jun 19, 2025