By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,941 Members | 1,766 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,941 IT Pros & Developers. It's quick & easy.

Where can I suggest an enchantment for Python Zip lib?

P: n/a
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
Jun 7 '07 #1
Share this Question
Share on Google+
9 Replies


P: n/a
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
Jun 7 '07 #2

P: n/a
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

Jun 7 '07 #3

P: n/a
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 <larry.ba...@websafe.comwrote:
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

Jun 8 '07 #4

P: n/a
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
Jun 9 '07 #5

P: n/a
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

Jun 9 '07 #6

P: n/a
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 <larry.ba...@websafe.comwrote:
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
Jun 9 '07 #7

P: n/a
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
Jun 10 '07 #8

P: n/a
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

Jun 13 '07 #9

P: n/a
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.
Jun 15 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.