Author loewis
Recipients Christophe Simonis, Garen, amaury.forgeotdarc, arekm, devurandom, doko, eric.araujo, georg.brandl, jreese, lars.gustaebel, leonov, loewis, nicdumz, nikratio, ockham-razor, pitrou, proyvind, rcoyner, thedjatclubrock, vstinner, ysj.ray
Date 2010-10-31.16:43:24
SpamBayes Score 2.263e-06
Marked as misclassified No
Message-id <1288543405.7.0.0144481310679.issue6715@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-10-31 16:43:26loewissetrecipients: + 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:25loewissetmessageid: <1288543405.7.0.0144481310679.issue6715@psf.upfronthosting.co.za>
2010-10-31 16:43:24loewislinkissue6715 messages
2010-10-31 16:43:24loewiscreate