[issue26379] zlib decompress as_bytearray flag

Changes by Terry J. Reedy : -- nosy: +nadeem.vawda, twouters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue26379] zlib decompress as_bytearray flag

Martin Panter added the comment: If you don’t know how large the buffer is when you call zlib.decompress(), there may be copying involved as the buffer is expanded. Have you found that the copying the bytes result into a bytearray is significantly worse than expanding a bytearray (e.g. timing

[issue26379] zlib decompress as_bytearray flag

Joe Jevnik added the comment: The recipe you showed looks like it is very complicated for the expected use case of decompressing all of the data into a mutable buffer. One difference I see with this and struct.pack_into or socket.recv_into is that in both of those cases we know how large our b

[issue26379] zlib decompress as_bytearray flag

Martin Panter added the comment: This is an unusual technique. I can’t think of any other standard library routine that returns a new bytearray instead of a bytes object. Normally there are sister functions with an -into() suffix that accept a pre-allocated buffer. Examples are BufferedIOBase.

[issue26379] zlib decompress as_bytearray flag

New submission from Joe Jevnik: Adds a keyword only flag to zlib.decompress and zlib.Decompress.decompress which marks that the return type should be a bytearray instead of bytes. The use case for this is reading compressed data into a mutable array to do further operations without requiring t