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.

Author josh.r
Recipients josh.r
Date 2016-01-20.17:49:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1453312183.38.0.668863762812.issue26166@psf.upfronthosting.co.za>
In-reply-to
Content
zlib.compressobj and zlib.decompressobj objects (actually zlib.Compress and zlib.Decompress, the other names are the function constructors I guess?) have a .copy() method, but don't implement `__copy__` or `__deepcopy__`. This leads to the mildly silly result that a copyable object can't be copied using the common copy protocol.

I see two solutions:

1. Implement `__copy__` and `__deepcopy__` directly for the zlib objects
2. Have the copy module include them in _copy_dispatch mapped to the existing _copy_with_copy_method (and use a similar approach for _deepcopy_dispatch, since AFAICT this isn't a case where deep copying differs from shallow copying)

The former makes for more C code in CPython, and would require matching updates in the zlib used by all alternate CPython interpreters, but is probably faster and introduces no new cross-module dependencies.

The latter would make zlib an import dependency of copy (or vice versa, if zlib messed with copy's internals on import), but involves only a trivial amount of new Python code and wouldn't require any changes by alternate Python implementations that used the core copy module (when they update to the new copy, they get the support for free).
History
Date User Action Args
2016-01-20 17:49:43josh.rsetrecipients: + josh.r
2016-01-20 17:49:43josh.rsetmessageid: <1453312183.38.0.668863762812.issue26166@psf.upfronthosting.co.za>
2016-01-20 17:49:43josh.rlinkissue26166 messages
2016-01-20 17:49:42josh.rcreate