|
|
 |
 |
 |
 |
Python Programming Language
|
 |
 |
 |
 |
|
|
|
|
Where can I suggest an enchantment for Python Zip lib?
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/comp.lang.python/browse_thread/thre...
Thanks for your help:
dd
"durumdara" <durumd @gmail.com> wrote in message
| Hi!
|
| Where can I ask it?
|
| I want to ask that developers change the Python's Zip lib in the next
| versions.
On the sourceforge tracker,
http://sourceforge.net/tracker/?group_id=5470
there is a Feature Request category.
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/comp.lang.python/browse_thread/thre...
> Thanks for your help:
> dd
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 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/comp.lang.python/browse_thread/thre...
> Thanks for your help:
> dd
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
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()
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.com> wrote:
> 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
In article <mailman.8788.1181210992.32031.python-l@python.org>,
durumdara <durumd @gmail.com> wrote: > [...]
(Sorry, couldn't resist.)
--
Aahz (a@pythoncraft.com) <*> http://www.pythoncraft.com/
"as long as we like the same operating system, things are cool." --piranha
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
On Sat, 09 Jun 2007 11:41:27 -0700, Paul McGuire <p@austin.rr.com>
declaimed the following in comp.lang.python:
> 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
compare Kah's hypnotic stare as a form of "enchantment"...
"Trussst in Meeee"
--
Wulfraed Dennis Lee Bieber KD6MOG
wlfr@ix.netcom.com wulfr@bestiaria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: web-a@bestiaria.com)
HTTP://www.bestiaria.com/
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.com> wrote:
So what is the problem? Not updating the process for 8-10 seconds
should be just fine for most applications.
-Larry
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
|
|
|
|
|
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc