This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author alanmcintyre
Recipients alanmcintyre, ehuss, gvanrossum
Date 2008-01-11.14:18:32
SpamBayes Score 0.004473056
Marked as misclassified No
Message-id <1200061119.29.0.415081279499.issue1622@psf.upfronthosting.co.za>
In-reply-to
Content
Currently the extra field data is only parsed when it contains Zip64
extended information.  It could probably be broken up into a list of
(id, data) pairs at a minimum for all data types, since the spec says
that's the structure that "should" be used.  

I don't know whether the results of that parse should be kept in a new
slot; putting it in the ZipInfo.extra slot would probably be bad for
2.6, since users might be counting on the current behavior of a raw
chunk of data still being there.  Does anybody else have any suggestions
for this?
History
Date User Action Args
2008-01-11 14:18:39alanmcintyresetspambayes_score: 0.00447306 -> 0.004473056
recipients: + alanmcintyre, gvanrossum, ehuss
2008-01-11 14:18:39alanmcintyresetspambayes_score: 0.00447306 -> 0.00447306
messageid: <1200061119.29.0.415081279499.issue1622@psf.upfronthosting.co.za>
2008-01-11 14:18:32alanmcintyrelinkissue1622 messages
2008-01-11 14:18:32alanmcintyrecreate