Where can I suggest an enchantment for Python Zip lib?

[durumdara]

Hi!

Where can I ask it?

I want to ask that developers change the Python's Zip lib in the next
versions.
The Zip lib not have a callback procedure. When I zip something, I don't
know, what is the actual position of the processing, and how many bytes
remaining.
It is simply rewriteable, but when I get new Python, it is forget this
thing again...

So some callback needed for it, if possible. With this I can abort
processing and I can show the actual state when I processing a large file.

See this thread:
http://groups.google.com.kh/group/co...b9b1c286d9af7b

Thanks for your help:
dd

[Larry Bates]

durumdara wrote:

Hi!

Where can I ask it?

I want to ask that developers change the Python's Zip lib in the next
versions.
The Zip lib not have a callback procedure. When I zip something, I don't
know, what is the actual position of the processing, and how many bytes
remaining.
It is simply rewriteable, but when I get new Python, it is forget this
thing again...

So some callback needed for it, if possible. With this I can abort
processing and I can show the actual state when I processing a large file.

See this thread:
http://groups.google.com.kh/group/co...b9b1c286d9af7b
Thanks for your help:
dd

You can easily find out roughly how many bytes are in your .ZIP archive
by using following:

zipbytes=Zobj.fp.tell()

Where Zobj is your zipfile instance. You don't need a callback.

Problem is ill defined for a better solution. You don't know how much
the "next" file will compress. It may compress a lot, not at all or
in some situations actually grow. So it is difficult (impossible?) to
know how many bytes are remaining. I have a rough calculation where
I limit the files to 2Gb, but you must set aside some space for the
table of contents that gets added at the end (whose size you don't
actually know either). So I use:

maxzipbytesupperlimit=int((1L<<31)-(8*(1<<20)))

That is 2Gb-8Mb maximum TOC limit of a zip file.

I look at zipbytes add the uncompressed size of the next file, if it
exceeds maxzipbytesupperlimit, I close the file and move to the next
zip archive. If it is smaller, I add the file to the archive.

Hope this helps.

-Larry

[Larry Bates]

durumdara wrote:

Hi!

Where can I ask it?

I want to ask that developers change the Python's Zip lib in the next
versions.
The Zip lib not have a callback procedure. When I zip something, I don't
know, what is the actual position of the processing, and how many bytes
remaining.
It is simply rewriteable, but when I get new Python, it is forget this
thing again...

So some callback needed for it, if possible. With this I can abort
processing and I can show the actual state when I processing a large file.

See this thread:
http://groups.google.com.kh/group/co...b9b1c286d9af7b
Thanks for your help:
dd

You can easily find out roughly how many bytes are in your .ZIP archive
by using following:

zipbytes=Zobj.fp.tell()

Where Zobj is your zipfile instance. You don't need a callback.

Problem is ill defined for a better solution. You don't know how much
the "next" file will compress. It may compress a lot, not at all or
in some situations actually grow. So it is difficult (impossible?) to
know how many bytes are remaining. I have a rough calculation where
I limit the files to 2Gb, but you must set aside some space for the
table of contents that gets added at the end (whose size you don't
actually know either). So I use:

maxzipbytesupperlimit=int((1L<<31)-(8*(1<<20)))

That is 2Gb-8Mb maximum TOC limit of a zip file.

I look at zipbytes add the uncompressed size of the next file, if it
exceeds maxzipbytesupperlimit, I close the file and move to the next
zip archive. If it is smaller, I add the file to the archive.

Hope this helps.

-Larry

[durumdara]

Hi Larry!

durumdara wrote:
You can easily find out roughly how many bytes are in your .ZIP archive
by using following:

zipbytes=Zobj.fp.tell()

The main problem is not this.
I want to write a backup software, and I want to:
- see the progress in the processing of the actual file
- abort the progress if I need it
If I compress small files, I don't have problems.
But with larger files (10-20 MB) I get problems, because the zipfile's
method is uninterruptable.
Only one way I have to control this: if I modify the ZipFile module.

dd

On Jun 7, 8:26 pm, Larry Bates <[e-mail]:

Where Zobj is your zipfile instance. You don't need a callback.

Problem is ill defined for a better solution. You don't know how much
the "next" file will compress. It may compress a lot, not at all or
in some situations actually grow. So it is difficult (impossible?) to
know how many bytes are remaining. I have a rough calculation where
I limit the files to 2Gb, but you must set aside some space for the
table of contents that gets added at the end (whose size you don't
actually know either). So I use:

maxzipbytesupperlimit=int((1L<<31)-(8*(1<<20)))

That is 2Gb-8Mb maximum TOC limit of a zip file.

I look at zipbytes add the uncompressed size of the next file, if it
exceeds maxzipbytesupperlimit, I close the file and move to the next
zip archive. If it is smaller, I add the file to the archive.

Hope this helps.

-Larry

[Aahz]

In article <ma***************************************@python. org>,
durumdara <du*******@gmail.comwrote:

>
[...]

Click your heels together three times and say, "Abracadabra!"
(Sorry, couldn't resist.)
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha

[Paul McGuire]

Hogwarts.

Sorry, I couldn't resist either.

I'm sure you meant to say "enhancement" - an "enchantment" is a magic
spell, often used to lull an unsuspecting victim into some sort of
compliance or trance. Actually, if you have an *enchantment* for
Python, I'm sure several people on this list would be interested. :)

But yes, *enhancement* requests can be posted on the SF feature
request list. You may need to more clearly define what kind of data
these zlib callbacks would receive, and under what conditions they
would be called.

-- Paul

[Larry Bates]

durumdara wrote:

Hi Larry!

>durumdara wrote:
You can easily find out roughly how many bytes are in your .ZIP archive
by using following:

zipbytes=Zobj.fp.tell()

The main problem is not this.
I want to write a backup software, and I want to:
- see the progress in the processing of the actual file
- abort the progress if I need it
If I compress small files, I don't have problems.
But with larger files (10-20 MB) I get problems, because the zipfile's
method is uninterruptable.
Only one way I have to control this: if I modify the ZipFile module.

dd

On Jun 7, 8:26 pm, Larry Bates <[e-mail]:

On my 3 year old 3Ghz Pentium III it takes about 8 seconds to zip 20Mb file.
So what is the problem? Not updating the process for 8-10 seconds
should be just fine for most applications.

-Larry

[Anders J. Munch]

durumdara wrote:

Only one way I have to control this: if I modify the ZipFile module.

Since you already have the desired feature implemented, why don't you submit a
patch.

See http://www.python.org/patches/

- Anders

[durumdara]

On my 3 year old 3Ghz Pentium III it takes about 8 seconds to zip 20Mb file.

So what is the problem? Not updating the process for 8-10 seconds
should be just fine for most applications.

-Larry

The problem, that:
- I want to process 100-200 MB zip files.
- I want to abort in process
- I want to know the actual position
- I want to slow the operation sometimes!

Why I want to slow?

The big archiving is slow operation. When it is slow, I want to
working with other apps while it is processing.

So I want to slow the zipping with time.sleep, then the background
thread is not use the full CPU...
I can work with other apps.

dd

[Tim Roberts]

durumdara <du*******@gmail.comwrote:

>
The problem, that:
- I want to process 100-200 MB zip files.
- I want to abort in process
- I want to know the actual position
- I want to slow the operation sometimes!

Why I want to slow?

The big archiving is slow operation. When it is slow, I want to
working with other apps while it is processing.

So I want to slow the zipping with time.sleep, then the background
thread is not use the full CPU...
I can work with other apps.

Surely a more intelligent (and much easier) solution would be to reduce the
priority of your archiving process. Your operating system is far better
equipped to share the CPU than you are.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.