This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients Arfrever, martin.panter, nikratio, pitrou, serhiy.storchaka, wolma
Date 2015-03-30.03:02:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1427684535.49.0.251144691657.issue23529@psf.upfronthosting.co.za>
In-reply-to
Content
Patch v9:

* Incorporated _PaddedFile.rewind() into seek() for simplicity
* Reverted to support fast-forwarding in non-seekable streams again
* Factored common checks into _check_can_seek()
* Documented “mtime” attribute and implemented it as a read-only decompression-only property

Antoine highlighted the fact that BufferedReader.peek() does not guarantee how much data it returns, so I removed the code trying to return at least 100 bytes.

I revisited merging the gzip read() loop with the others, but gave up again. I tried adding calls to _start_member() and _end_member(), with more “if” statements and flags to account for the different edge cases. But then I remembered the “needs_input” flag of LZMA and bzip versus the “unconsumed_tail” of zlib. Handling this would probably require another delegation to a new _decompress_chunk() method, at which point I think the whole read() method will probably just be a mess of hacks trying to marry the two not-quite-compatible implementations. So I think it is better to override read() with a gzip-specific implementation, unless someone wants to prove me wrong with their own patch :)
History
Date User Action Args
2015-03-30 03:02:15martin.pantersetrecipients: + martin.panter, pitrou, Arfrever, nikratio, serhiy.storchaka, wolma
2015-03-30 03:02:15martin.pantersetmessageid: <1427684535.49.0.251144691657.issue23529@psf.upfronthosting.co.za>
2015-03-30 03:02:15martin.panterlinkissue23529 messages
2015-03-30 03:02:15martin.pantercreate