Message236706
| Author |
nikratio |
| Recipients |
martin.panter, nikratio, pitrou, serhiy.storchaka |
| Date |
2015年02月26日.21:10:02 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1424985002.7.0.82215651227.issue23528@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Especially now that this is only going to go into 3.5, I think it makes more sense to handle GzipFile, LZMAFile and BZ2File all in one go. Looking at the code, otherwise there's going to be a lot of duplication.
How about introducing a base class 'CompressedFile' that defines most of the logic that's currently in LZMAFile (including the max_size patch from issue 23529), and having {LZMA,BZ2,Gzip}File all inherit from that base?
BZ2File and LZMAFile would probably only need to define their own constructor to instantiate the proper compressor/decompressor object.
GzipFile would need to additionally overwrite read() and write() in order to handle the CRC and gzip header. But I think both methods could still be written to call super().read/write().
Did I miss something? |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2015年02月26日 21:10:02 | nikratio | set | recipients:
+ nikratio, pitrou, martin.panter, serhiy.storchaka |
| 2015年02月26日 21:10:02 | nikratio | set | messageid: <1424985002.7.0.82215651227.issue23528@psf.upfronthosting.co.za> |
| 2015年02月26日 21:10:02 | nikratio | link | issue23528 messages |
| 2015年02月26日 21:10:02 | nikratio | create |
|