Alan McIntyre added the comment: 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? __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1622> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
