Author nobody
Recipients
Date 2001-10-04.15:54:14
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
There exist two methods to write to a ZipFile

     write(self, filename, arcname=None, compress_type=None)  
     writestr(self, zinfo, bytes)

but only one to read from it

     read(self, name)

Additionally, the two 'write's behave differently with respect to compression.

---
(a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a ZipFile, 
     but 'read' is not the reverse operation. 'read' should be called 'readstr' since it 
     much better matches to 'writestr'.

(b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a file, 
     or into the ZipFile? It would be more obvious if ZipFile has 4 methods which 
     pair-wise fit together:

     writestr (self, zinfo, bytes)
          # same as now
     readstr (self, name)
          # returns bytes (as string), currently called 'read'
          # 'read' could still live but should be deprecated
     add (self, filename, arcname=None, compress_type=None)
          # currently 'write'
          # 'write' could still live but should be deprecated
     extract (self, name, filename, arcname=None)
          # new, desired functionality

(c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that was 
     passed to the constructor of 'ZipFile'. Currently, 'write' does it, 'writestr' via 
     zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' :-( 
     It should not do that! It rather should:
     - allow more parameters in the signature of the constructor
        to also pass the compression type (and some other attributes, too)
     - default to 'None', so that 'writestr' can see this, and then take 
        the default from the 'ZipFile' instance.



History
Date User Action Args
2007-08-23 16:01:37adminlinkissue467924 messages
2007-08-23 16:01:37admincreate