Message120068
After starting to review the code, I'm becoming skeptical whether this is the right approach. This does way to much action in C, and thus becomes complicated but also limited.
An alternative approach would be to just expose lzma_code to Python, and then integrate that into the io architecture, i.e. as a subclass of RawIOBase. I.e. LZMAFile would go; if you want to compress to a file, use FileIO instead, and wrap that with a LZMAIO (say). LZMACompressor and Decompressor could stay if desired, although it seems more liblzma-like to have a single object for both compression and decompression.
In addition, I find the options object too complicated. It seems to serve documentation purposes only, so I wonder whether it could be reduced in code size. |
|
Date |
User |
Action |
Args |
2010-10-31 16:43:26 | loewis | set | recipients:
+ loewis, georg.brandl, doko, amaury.forgeotdarc, arekm, lars.gustaebel, pitrou, vstinner, nicdumz, eric.araujo, Christophe Simonis, rcoyner, proyvind, nikratio, leonov, devurandom, Garen, ysj.ray, thedjatclubrock, ockham-razor, jreese |
2010-10-31 16:43:25 | loewis | set | messageid: <1288543405.7.0.0144481310679.issue6715@psf.upfronthosting.co.za> |
2010-10-31 16:43:24 | loewis | link | issue6715 messages |
2010-10-31 16:43:24 | loewis | create | |
|