[issue30000] Inconsistency in the zlib module
Ellison Marks added the comment: Erm, is there anyone else we should poke for their opinion then? -- ___ Python tracker <http://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30017] zlib.error: Error -2 while flushing: inconsistent stream state
Ellison Marks added the comment: At a guess, when encoder goes out of scope, it closes the underlying file object. Then, on exiting the with block, the zipfile tries to take some action with the closed file and errors out? -- nosy: +Ellison Marks ___ Python tracker <http://bugs.python.org/issue30017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30000] Inconsistency in the zlib module
Ellison Marks added the comment: I'm not sure I agree with that. The docs for compressobj just say "Returns a compression object, to be used for compressing data streams that won’t fit into memory at once." Which I don't think says much about the complexity aspect. Whether you're compressing a smaller bit of data or a stream, I think the optional parameters in compressobj are just as applicable to compress. When you've got an in-memory chunk of data, it seems to be going out of the way to construct a compressobj just to get at the optional parameters. -- ___ Python tracker <http://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30000] Inconsistency in the zlib module
Ellison Marks added the comment: I made a try at a patch for this. My C is rudimentary at best, so I was hoping someone could look it over before I submitted a PR? https://github.com/gotyaoi/cpython/commit/2906fc9069ce6ec4888a547b5088ef9177a21c9a -- ___ Python tracker <http://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30000] Inconsistency in the zlib module
New submission from Ellison Marks: In the zlib module, three of the methods support the wbits parameter, those being zlib.compressobj, zlib.decompress and zlib.decompressobj. zlib.compress does not support the wbits parameter. Looking at the source for these functions, those that support the wbits parameter use the "advanced" version of the zlib functions, deflateInit2 and inflateInit2, whereas zlib.compress uses the "basic" function deflateInit. The effect of this is that while you can decode from zlib data with non-default wbits values in one call with zlib.decompress, you cannot encode to zlib data with non-default wbits in one call with zlib.compress. You need to take to extra step of creating a compression object with the appropriate values, then use that to compress the data. eg: zlib.compress(data) # can't use wbits here vs. compressor = zlib.compressobj(wbits=16+zlib.MAX_WBITS) compressor.compress(data) + compressor.flush() Some quick benchmarking shows little speed difference between the two implementations: $ python -m timeit -s 'import zlib' -s 'import random' -s 'import string' -s 's="".join(random.choice(string.printable) for _ in xrange(1000))' 'zlib.compress(s)' 10 loops, best of 3: 356 msec per loop $ python -m timeit -s 'import zlib' -s 'import random' -s 'import string' -s 's="".join(random.choice(string.printable) for _ in xrange(1000))' 'compressor=zlib.compressobj()' 'compressor.compress(s)+compressor.flush()' 10 loops, best of 3: 364 msec per loop so I can't see any downside of switching zlib.compress to the "advanced" implementation and exposing the extra parameters to python. -- components: Library (Lib) messages: 291201 nosy: Ellison Marks priority: normal severity: normal status: open title: Inconsistency in the zlib module type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26571] turtle regression in 3.5
Ellison Marks added the comment: Just as an update, I've been working around this by manually setting TurtleScreen._RUNNING to True before calling Turtle() again, which produces the desired behaviour in both 3.4 and 3.5. Haven't noticed any bad effects so far. -- ___ Python tracker <http://bugs.python.org/issue26571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26571] turtle regression in 3.5
New submission from Ellison Marks: I noticed some odd behaviour when running some turtle code I wrote using python 3.5. A simplified example: >>> from turtle import Turtle >>> t = Turtle() >>> t.getscreen().bye() # or manually close the turtle window >>> t2 = Turtle() Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.5/turtle.py", line 3816, in __init__ visible=visible) File "/usr/lib64/python3.5/turtle.py", line 2557, in __init__ self._update() File "/usr/lib64/python3.5/turtle.py", line 2660, in _update self._update_data() File "/usr/lib64/python3.5/turtle.py", line 2646, in _update_data self.screen._incrementudc() File "/usr/lib64/python3.5/turtle.py", line 1292, in _incrementudc raise Terminator turtle.Terminator >>> This code works under 3.4, opening a new turtle window the second time Turtle() is called. Under 3.5, a blank white window opens. This seems to be related to https://hg.python.org/cpython/rev/1628484c9408, as the only point that raises Terminator is guarded by a check for `if not TurtleScreen._RUNNING:` -- components: Library (Lib) messages: 261840 nosy: Ellison Marks priority: normal severity: normal status: open title: turtle regression in 3.5 type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue26571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
