ZipFile.writestr "compression_type" argument

[ronaldoussoren]

BPO	6003
Nosy	@ronaldoussoren, @pitrou, @benjaminp
Files	zipfile_writestr.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ronaldoussoren'
closed_at = <Date 2010-02-07.20:24:58.036>
created_at = <Date 2009-05-12.09:36:44.973>
labels = ['type-feature', 'library']
title = 'ZipFile.writestr "compression_type" argument'
updated_at = <Date 2010-02-07.20:24:58.034>
user = 'https://github.com/ronaldoussoren'

bugs.python.org fields:

activity = <Date 2010-02-07.20:24:58.034>
actor = 'ronaldoussoren'
assignee = 'ronaldoussoren'
closed = True
closed_date = <Date 2010-02-07.20:24:58.036>
closer = 'ronaldoussoren'
components = ['Library (Lib)']
creation = <Date 2009-05-12.09:36:44.973>
creator = 'ronaldoussoren'
dependencies = []
files = ['14018']
hgrepos = []
issue_num = 6003
keywords = ['patch']
message_count = 8.0
messages = ['87610', '87625', '87627', '87629', '88096', '88097', '88437', '99015']
nosy_count = 3.0
nosy_names = ['ronaldoussoren', 'pitrou', 'benjamin.peterson']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue6003'
versions = ['Python 3.1', 'Python 2.7', 'Python 3.2']

[ronaldoussoren]

Class zipfile.ZipFile has two methods for adding data to a zipfile:
'write' and 'writestr'.

The former has a "compression_type" argument that can be used to specify
the compression to be used. That latter doesn't have that argument.

Could a "compression_type" argument be added to "writestr" as well? I
regularly create zipfiles from scratch using the writestr method to add
content and currently have to modify the 'compression' attribute of the
zipfile object to control compression and that leads to ugly code.

The other alternative is to use a ZipInfo object as the archive-name of
the newly added file, but that leads to even uglier code.

[pitrou]

This sounds like a good idea. Can you provide a patch (including tests)?

[ronaldoussoren]

I will.

I guess it's too late to merge this into 3.1 (as the first beta has
already been released).

[pitrou]

I guess it's too late to merge this into 3.1 (as the first beta has
already been released).

Since the change should be small and uncontroversial, I think it could
go in.
Benjamin has the final word.

[ronaldoussoren]

The attached patch implements my proposal, including documentation and
tests. I'm not 100% happy about the tests, they may be a bit too minimal.

[ronaldoussoren]

Argh... The patch includes an update to configure.in, please ignore that
bit.

[pitrou]

The patch looks ok. It can certainly go in trunk, as for 3.1 it's up to
Benjamin to decide.
Note: the docs should state that the new argument appeared in 2.7.

[ronaldoussoren]

Committed in r78097 (trunk) and r78098 (3.2). This includes the documentation change suggested in msg88437