Message 59709 - Python tracker

➜

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.

In-reply-to
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>

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?

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:39	alanmcintyre	set	spambayes_score: 0.00447306 -> 0.004473056 recipients: + alanmcintyre, gvanrossum, ehuss
2008年01月11日 14:18:39	alanmcintyre	set	spambayes_score: 0.00447306 -> 0.00447306 messageid: <1200061119.29.0.415081279499.issue1622@psf.upfronthosting.co.za>
2008年01月11日 14:18:32	alanmcintyre	link	issue1622 messages
2008年01月11日 14:18:32	alanmcintyre	create

homepage