[Patches] [ python-Patches-448474 ] Add support for 'tell()' to gzip.GzipFile

[noreply@sourceforge.net]

Patches item #448474, was opened at 2001-08-06 11:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Petrone (jpetrone)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for 'tell()' to gzip.GzipFile

Initial Comment:
The GzipFile class is missing a couple important attributes that
normal fileobjs expose(tell, seek, fileno, readinto).  tell() is a 
trivial one that I really needed for a project, so I added.

Here's the patch against current cvs(8/6/01)

If this is seen as a useful addition, let me know, and I will do the
rest.




----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2001-08-08 09:12

Message:
Logged In: YES 
user_id=21627

The patch looks good to me now, as well. I was about to 
check it in when I remembered one thing: Would you 
volunteer to write documentation for the new methods, or 
otherwise update libgzip.tex? Don't worry about the tex 
mechanics too much; I will adjust the markup before 
checking it in - but it would help if you could draft the 
text.
Ideally, test cases would be appreciated as well...


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 09:00

Message:
Logged In: YES 
user_id=6380

OK, now it makes sense.  Martin, what do you think?  Anybody
else?

----------------------------------------------------------------------

Comment By: Jason Petrone (jpetrone)
Date: 2001-08-08 08:57

Message:
Logged In: YES 
user_id=71210

Yes, I have already written seek() for GzipFile.  I needed
both seek() and tell() for the tarfile module I am writing.
I didn't include it at first since it is more to wade
through.

My seek() uses the same slow procedure as zlib's gzseek.

I'm attaching the updated patch.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 08:10

Message:
Logged In: YES 
user_id=6380

Are you offering to implement seek() as well? That would be
useful then. I don't see the point of fileno(), and
readinto() might not be doable without writing C code. But
just seek() and tell() are a laudable goal.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 08:01

Message:
Logged In: YES 
user_id=6380

I don't see the point of supporting tell() without seek(). 
Why is this useful?

----------------------------------------------------------------------

Comment By: Jason Petrone (jpetrone)
Date: 2001-08-08 06:35

Message:
Logged In: YES 
user_id=71210

tell() should return the position in the uncompressed 
stream because gzipFile.fileobj.tell() already gives the 
position in the compressed stream and these are the same
semantics that the GNU zlib library on which this is based
uses.

The file object like functions in GNU zlib support tell and
seek.  It seems easonable that the python wrappers for it
should provide them as well.

Just in case I've managed to sway your position, I am 
attaching a fixed patch.  I had done `cvs diff gzip.py -u`
instead of `cvs diff -u gzip.py` by accident.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-08-07 22:02

Message:
Logged In: YES 
user_id=21627

Please use context (-c) or unified (-u) patch following  
the SF FAQ 
(http://python.sourceforge.net/sf-faq.html#patches).

As for the patch itself: It seems not so clear that tell() 
should really give the position in the uncompressed 
stream; why is that more useful than the position in the 
compressed stream? Also, it seems that .tell() is useless 
without .seek. However, I pretty much doubt you can do 
.seek on top of zlib: to seek to a certain position, you 
would need the state of the compression engine at this 
position, no?

Unless I'm missing something here, I would therefore 
recommend to reject this patch, and advise you to derive a 
class from GzipFile that has the tell semantics you 
desire, for use in your application.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448474&group_id=5470