Message120068
| 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.2630047e-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: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 |
|