Upon actual read of a gzipped file, there is a check
to see if you are already at the end of the file. This
is done by saving your position, seeking to the end,
and comparing that tell(). It is more efficient to
simply increment position + 1.

Efficiency gain is nearly insignificant, but this
patch will greatly decrease the size of my next one. :)

NOTE: all version of gzip.py do this.

Logged In: YES 
user_id=35752

This looks like a pointless change to me.  It's probably
less efficient with the patch because there is an extra
Python int add.  Why don't you just submit the real patch? :)

Rejected.

Logged In: YES 
user_id=87721

It is more efficient for the majority of gzipped files
(if very small files are not in the majority).

The "real" patch will be (once I give it a bit more
polish/tuning --- using in production code soon) a class
called GzipStream. Ie. it will allow high level access to
any arbitrary file-like "stream" (eg. a gzipped
socket stream) which are not generally "seekable". I do
this via inheriting GzipFile and extending upon it...
but I rewrite the _read method with a one line change.

Anyway, that is my logic. Question to you: should this be
included within gzip.py or in its own module (eg. 
gzipstream)?

Logged In: YES 
user_id=87721

It is more efficient for the majority of gzipped files
(if very small files are not in the majority).

The "real" patch will be (once I give it a bit more
polish/tuning --- using in production code soon) a class
called GzipStream. Ie. it will allow high level access to
any arbitrary file-like "stream" (eg. a gzipped
socket stream) which are not generally "seekable". I do
this via inheriting GzipFile and extending upon it...
but I rewrite the _read method with a one line change.

Anyway, that is my logic. Question to you: should this be
included within gzip.py or in its own module (eg. 
gzipstream)?

Logged In: YES 
user_id=35752

Why would it be more efficient?  Assuming the OS is not
implemented by a silly person, a seek just updates
an offset in the in-memory file descriptor structure.

Regarding your GzipStream, it sounds like making it part
of gzip.py would be okay.