Barry Warsaw writes:

On Tue, 2003-07-22 at 10:43, Thomas Heller wrote:

...

Is it too late to get this small patch in?

http://www.python.org/sf/775637

I'm hesitating to raise the priority...

I'm not a zipimport export but the description seems to imply it's a new feature not a bug fix.

There are several ways to argue that is *is* a bug fix: zipimport.c doesn't handle zip files which are no problem for the zipfile module. zipimport.c, as it is now, looks for the endof_central_dir header relative to the *end of the file*: fseek(fp, -22, SEEK_END); header_end = ftell(fp); if (fread(endof_central_dir, 1, 22, fp) != 22) { ... but then goes on positioning relative to the *start of the file*: fseek(fp, header_offset, 0); /* Start of file header */ l = PyMarshal_ReadLongFromFile(fp); if (l != 0x02014B50) break; /* Bad: Central Dir File Header */ OTOH, fixing this 'bug' allows py2exe using the zipimport hook. Thanks, Thomas

Barry Warsaw writes:

On Tue, 2003-07-22 at 11:25, Thomas Heller wrote:

...

There are several ways to argue that is *is* a bug fix: zipimport.c doesn't handle zip files which are no problem for the zipfile module.

Okay, that does seem like a problem. SF's web site is dead again, but go ahead and check it in when it comes back up.

"Moore, Paul" writes:

I thought this already worked, and I'd like it to. But as it doesn't, I'd have to agree that it's a new feature and not appropriate at this late stage (much as I'd like it to go in).

[Mumble, click] Ah yes. See http://www.python.org/sf/669036 - Just meant to get to this, but didn't manage to. On the other hand, the fact that it's logged as a bug may mean it makes sense to allow it.

It would be best if someone else who really uses zipimports would be able to test it - I really don't want to break anything. Thomas

martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes:

Thomas Heller writes:

...

It would be best if someone else who really uses zipimports would be able to test it - I really don't want to break anything.

Then 2.3 should go unchanged. If there is a way to construct proper zipfiles for zipimports, this should be sufficient. Any support for additional "kinds" of zipfiles should count as a new feature.

It's already checked in. Thomas

Thomas Heller wrote:

Thomas Heller writes:

...

martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes:

...

Thomas Heller writes:

...

It would be best if someone else who really uses zipimports would be able to test it - I really don't want to break anything.

Then 2.3 should go unchanged. If there is a way to construct proper zipfiles for zipimports, this should be sufficient. Any support for additional "kinds" of zipfiles should count as a new feature.

It's already checked in.

Should it be backed out again? Can the powers please decide?

I'm going to test it with my stuff today or tomorrow. I would very much like this to go in. It's had a bug report for a long time, and since it's a *property* of zip files they can be prepended with arbitrary junk, it's indeed a bug fix, not a new feature. Just