New submission from Andrew McNabb <amcn...@mcnabbs.org>:
The stream encoder for the zlib_codec doesn't use the incremental encoder, so
it has limited usefulness in practice. This is easiest to show with an example.
Here is the behavior with the stream encoder:
>>> filelike = io.BytesIO()
>>> wrapped = codecs.getwriter('zlib_codec')(filelike)
>>> wrapped.write(b'hello')
>>> filelike.getvalue()
b'x\x9c\xab\x00\x00\x00y\x00y'
>>> wrapped.write(b'x')
>>> filelike.getvalue()
b'x\x9c\xab\x00\x00\x00y\x00yx\x9c\xab\x00\x00\x00y\x00y'
>>>
However, this is the behavior of the incremental encoder:
>>> ienc = codecs.getincrementalencoder('zlib_codec')()
>>> ienc.encode(b'x')
b'x\x9c'
>>> ienc.encode(b'x', final=True)
b'\xab\xa8\x00\x00\x01j\x00\xf1'
>>>
The stream encoder is apparently encoding each write as an individual block,
but the incremental encoder buffers until it gets a block that's large enough
to be meaningfully compressed.
Fixing this may require addressing a separate issue with stream encoders.
Unlike with the GzipFile module, closing a stream encoder closes the underlying
file. If this underlying file is a BytesIO, then closing makes it free its
buffer, making it impossible to get at the completed file.
----------
components: IO
messages: 152029
nosy: amcnabb
priority: normal
severity: normal
status: open
title: Stream encoder for zlib_codec doesn't use the incremental encoder
type: behavior
versions: Python 3.2
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13881>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
