You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In release 0.11.0, although flush() is now supported on decompressobj, it returns None unlike zlib.decompressobj which returns empty string.
From the python documentation:
Decompress.flush([length])
All pending input is processed, and a string containing the remaining uncompressed output is returned. After calling flush(), the decompress() method cannot be called again; the only realistic action is to delete the object.
The optional parameter length sets the initial size of the output buffer.
This behavior makes special handling necessary for zstandard decompressor when using the return value directly in things like file object's write(), which do not accept None.
In release 0.11.0, although
flush()
is now supported ondecompressobj
, it returnsNone
unlikezlib.decompressobj
which returns empty string.From the python documentation:
This behavior makes special handling necessary for zstandard decompressor when using the return value directly in things like file object's
write()
, which do not acceptNone
.Can we consider returning empty string instead?
Originally posted by @vnair81 in #65 (comment)
The text was updated successfully, but these errors were encountered: