Stephen J. Turnbull added the comment:
Thanks for followup! I was just about to write you, now that 3.6 is out.
Season's Greetings!
First, how do you propose to proceed with issue28115 ("use argparse for the
ZipFile module")? If you expect to commit that first (I'm in no hurry for this
patch, BTW, as long as it gets into 3.7 I'm happy), this issue should depend on
it and use argparse too.
I don't see any good reason for allowing non-UTF-8 encoding to a file open for
writing, and a good reason (the ZipFile standard) for not allowing it.
Certainly the CLI should not allow it, any more than it does now. At least in
my experiments InfoZip and the default zip utilities on Windows and Mac DTRT
with UTF-8 zipfiles, so there is no absolute need for writing nonconforming
zipfiles. If you want to block on a convert-to-UTF-8 option I can do that (but
I don't need it myself). (Note to self: if writing to existing zipfile is
extension of existing file, need to prevent mixed encodings. Also warn about
conversion.)
I thought I checked that comments were decoded. Maybe that's only on the UTF-8
path? Or maybe I needed more coffee. (Hope so, that would be a messy problem
if ASCII/Latin1 returns bytes and UTF-8 returns str!) I'll think about this.
Yes, it's a backwards-compatibility issue so needs care. Would be weird if
names are decoded but other metadata (comments) not, though. Surely someone
would complain if they actually used comments? (I'm thinking maybe a
compatibility break might be OK? With deprecation cycle?) I expect to check
all execution paths accessing metadata and have a proposed patch by 12/31.
I think I'm still short some tests, will check and write them if needed.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue28080>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
