Repository navigation
zipfile.ZipInfo._compresslevel should be public. #113971
Description
Feature or enhancement
Proposal:
Today people pass ZipInfo instances into APIs that accept them such as ZipFile.writestr() in order to control how individual items are put into a zip archive as such:
zip_info = zipfile.ZipInfo(filename=filename, date_time=desired_timestamp)
zip_info.compress_type = this_files_compress_type
# This attribute is sadly not public; manual creation of ZipInfo objects
# is uncommon. Without this we cannot write compressed files with our
# own overridden info.
zip_info._compresslevel = this_files_compress_level # pylint: disable=protected-access
zip_info.external_attr = desired_permissions
zip_file.writestr(zip_info, data)There is no reason for ._compresslevel to be protected with an _. We should make it public as it is useful.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
Metadata
Metadata
Assignees
Projects
- Status
Activity
gpshead commentedon Jan 12, 2024
In general I'd like to expand upon the ability for ZipFile writing APIs to take a
ZipInfoinstance so making ZipInfo easier to use while retaining compatibility helps. This is one simple little part of that.#113925 expands write to accept a
ZipInfo. (Even if we don't decide to accept that PR'sprecompressed=feature, keeping the ability to pass ZipInfo and file objects in more places as implemented there would be good - We've got code at work that'd be more efficient that way)gh-113971: Make `zipfile.ZipInfo._compresslevel` public as `.compress…
pythongh-113971: Make `zipfile.ZipInfo._compresslevel` public as `.co…
pythongh-113971: Make `zipfile.ZipInfo._compresslevel` public as `.co…
pythongh-113971: Make `zipfile.ZipInfo._compresslevel` public as `.co…