homepage

> LZMAFile, LZMACompressor & LZMADecompressor are all inspired by and
> written to be as similar to bz2's for easier use & maintenance. I
> must admit that I haven't really put much thought into alternate ways
> to implement them beyond monkey see, monkey do.. ;)
My concern really is with LZMAFile only. It uses stdio, and it really
shouldn't - we are trying to drop stdio in Python, as it's causing too
many problems. LZMACompressor/Decompressor may be fine.
> LZMAOptions is a bit awkwardly written, but it doesn't serve
> documentation purposes only, it also exposes these values for max,
> min etc. to python (ie. as used by it's regression tests) and are
> also used when processing various compression options passed.
> 
> IMO it does serve a useful purpose, but certainly wouldn't hurt from
> being rewritten in some better way...
If you are willing to do that, here is what I propose: rename the module
to _lzma, drop options and lzmafile from _lzma. Then write lzma.py,
which re-introduces this Options class in pure Python, as well as
reintroduces LZMAFile, wrapping io.FileIO. The various constants that
go into options should be exposed from _lzma using
PyModule_AddIntConstant (except perhaps for the ones that you define
yourself, such as LZMA_BEST_SPEED)
That assumes, of course, that there is a need to provide backwards
compatibility. I would personally be fine with *just* having the LZMA
symbolic constants exposed, leaving it to the user to determine which
constant serves which purpose (e.g. guessing what LZMA_DICT_SIZE_MIN
and LZMA_DICT_SIZE_MAX do when there is a dict_size keyword parameter
isn't too hard). But then, having the various options explained
in a consistent manner may be useful enough to preserve the Options
class.