[Tutor] where to report a bug?

Rick Pasotto rick at niof.net
Sat Jul 26 19:00:05 CEST 2008


On Fri, Jul 25, 2008 at 03:11:57PM -0700, Dave Kuhlman wrote:
> On Fri, Jul 25, 2008 at 10:04:35AM -0400, Rick Pasotto wrote:
> > I have a script that works fine on my linux machine but bombs out when
> > run under windows using the exact same data files. The script downloads
> > a file then unzips it and then scans the resulting file for certain
> > records. Under Windows it gets a memory error in the unzip routine.
> > 
> > Where should I send the error report?
> 
> You might want to post your code here.  Someone might be able to
> suggest a fix (to your code) or at least a work-around.
> 
> One question -- Are you downloading the file and unzipping it with
> the zipfile module?  Or, are you downloading the file and then
> writing the file to disk.
> 
> If you are writing the file to disk, make sure that you open the
> file in binary mode, since a zipped file is binary data.  If you
> fail to do so, your code will work on Linux/UNIX, but not on
> Windows.  I've written code with that bug myself.

That was a good thought but when I double checked the code I found that
I was already opening the write file in 'wb' mode.

Here's where things stand now.

I searched comp.lang.python for 'zipfile' and found several messages
that talked about this error. It seems that Windows doesn't handle
memory allocation very well on large files (surprise, surprise). The
module was written to deal with small files and so that was not a
consideration in writing the module.

One of the messages included a workaround that replaced the 'write'
method with an 'explode' funtion that opperated on 8k chunks instead of
the whole file. This had the added advantage of my being able to tap
into the function to display a progress indicator.

Again, it worked fine on my linux machine but failed on Windows, but
this time with a different error. This error really surprises me.

The new explode function uses the zipfile.ZipInfo.file_offset attribute.
Windows reports that there is no such attribute. Turns out that while it
exists in 2.4, which is what I am still running, it does *not* exist in
2.5, which is what the python.org Windows installer uses. I have 2.5 on
my linux machine and when I run python2.5 there, ZipInfo.file_offset is
not in the dir(zipfile.ZipInfo) list. All the other attributes match.

Where did it go? And why? Was it intentionally removed? If so, why and
how do I get its functionality? I haven't spotted any reference to the
change in the changelists I've seen but maybe I haven't looked in the
right places.

What should be my next step?

-- 
"You are the only one who can use your ability. It is an awesome
 responsibility." -- Zig Zigler
    Rick Pasotto    rick at niof.net    http://www.niof.net


More information about the Tutor mailing list