homepage

The ZipExtFile class in zipfile module does not provide a seek method like GzipFile. As a result, it is hard to manipulate files without extract all the content.
For example, a very large tar file compressed with zip. The TarFile module can operate on file object, but need seek method. So the ZipExtFile instance return from ZipFile can not passed into TarFile.
This may seem strange but I encounter this on Samsung firmware.
In fact, the seek method in GzipFile or someother compressed format can be implemented in zipfile very easily. Here is my naive modification (nearly same as in GzipFile)

I'm -1 on adding the seek method with linear complexity. This looks as attractive nonsense to me. It would be better just make TarFile working with non-seekable streams.

Actually TarFile already works with non-seekable streams. Use TarFile.open() with mode='r|*' or like.
On other hand I'm not against the make non-compressed ZipExtFile seekable. It can be helpful in case when ZIP file is used just as a container for other files.

It would be great to have the ZipFileExt class seekable.
This would help in implementing features in other projects.
For example, pydicom would gain the ability to read from ZIP files, as mentioned in https://github.com/darcymason/pydicom/issues/219 

To add to this (without looking at the patch): I just to my astonishment learned that a ZipExtFile doesn't even support tell(). I can understand the seek being nontrivial... but the tell? It's a bytestream, and there is (isn't there?) a clear definition of what next byte a read(1) would deliver. It should be trivial to keep track of the (only ever increasing) file position.

Please be gentle, this is my first submission to python.
The use case for me was a recursive zip-within-a-zip situation. I wanted to allow the creation of a zipfile.ZipFile from an existing zipfile.ZipExtFile, but the lack of seek prevented this.
I simply treated forward seeks as a read, and backward seeks as a reset-and-read. The reset was the tricky part as it required restoring several original values such as the remaining compressed length, remaining data length, and the running crc32.
I pushed this into the latest upstream branch, but as I am testing this in v3.4 it should be easy to backport if necessary (I suspect not).
I based my fix on a little program that I wrote to test the feasibility of this idea. I am attaching that test program here.

New changeset 066df4fd454d6ff9be66e80b2a65995b10af174f by Gregory P. Smith (John Jolly) in branch 'master':
bpo-22908: Add seek and tell functionality to ZipExtFile (GH-4966)
https://github.com/python/cpython/commit/066df4fd454d6ff9be66e80b2a65995b10af174f