Mailing List Archive

"M.-A. Lemburg" wrote:
>
> Sure, for the sake of creating Python code archives, but
> your module is much more versatile: e.g. I could automatically
> create ZIP archives of log files or sets of other files and

OK, zipfile.py no longer complains about compression != 0

JimA

James C. Ahlstrom wrote:

> ftp://ftp.interet.com/pub/pylib.html

I feel that it smell a bit too much like a tool and too little like an general
programming api.

- It can only add disk files. The ability to write data to a zip entry through
a file-like object or from a string would make it more like an API, IMHO
- Some kind of access to the TOC entry fields (date, size, compressed
size etc) also seems like a nice feature.
- The data for an entry must be available in memory. Could be a problem
for huge files, but most like not in practical use.

I admit that I am fond of the api from java.util.zip.ZipFile and
java.util.zip.ZipOutputStream.

Regards,
Finn Bock

Finn Bock wrote:
>
> James C. Ahlstrom wrote:
>
> > ftp://ftp.interet.com/pub/pylib.html
>
> I feel that it smell a bit too much like a tool and too little like an general
> programming api.

It was meant to be an API except for writepy(), which is clearly a tool.

> - It can only add disk files. The ability to write data to a zip entry through
> a file-like object or from a string would make it more like an API, IMHO

I could add a method
writestr(self, string, year, month, day, hour, minute, second, ...)
There are a lot of fields required which usually come from the file.

> - Some kind of access to the TOC entry fields (date, size, compressed
> size etc) also seems like a nice feature.

This access is provided directly by self.TOC, and the fields are
documented.

> - The data for an entry must be available in memory. Could be a problem
> for huge files, but most like not in practical use.

I agree, but adding loops will make it slower. What do others think?

> I admit that I am fond of the api from java.util.zip.ZipFile and
> java.util.zip.ZipOutputStream.

I don't know this API. If writestr() is not sufficient, what
API would you like?

JimA

[I wrote]

> - It can only add disk files. The ability to write data to a zip entry through
> a file-like object or from a string would make it more like an API, IMHO

[JimA wrote]

>I could add a method
> writestr(self, string, year, month, day, hour, minute, second, ...)
>There are a lot of fields required which usually come from the file.

Something like that seems fine to me.

[I wrote]

> - Some kind of access to the TOC entry fields (date, size, compressed
> size etc) also seems like a nice feature.

[JimA answers]

>This access is provided directly by self.TOC, and the fields are
>documented.

Good enough. My bad, I was looking for getter methods. (me being a java dude)

[I wrote]

> I admit that I am fond of the api from java.util.zip.ZipFile and
> java.util.zip.ZipOutputStream.

[JimA asks]

>I don't know this API. If writestr() is not sufficient, what
>API would you like?

This is only meant as a source for inspiration, certainly as a request for
change. writestr would answer my complaint nicely. Below, only one ZipEntry can
be actively read or written to at a time. All the small details of performance
and implementation complexity are ignored.

class ZipFile:
def getEntry(name):
...
self.activeentry = ZipEntry(name)
return self.activeentry

class ZipEntry:
#enough methods and fields to fake file-ness to casual users like me.
def write(list): ...
def writelines(str): ...
def read(size=None): ...
def readlines(sizehint=-1): ...

def seek(offset): ...
def flush(): ...
def close(str): ...

def getSize(): ....
def getCompressedSize(): ....
def getFlags(): ....


regards,
finn