New submission from Matt Joiner <anacro...@gmail.com>: When reading from the fileobj passed in it's constructor, zipfile.ZipExtFile passes a long into fileobj.read(). This is not normally an issue, except in io.BytesIO, for which the source is in C, and throws TypeError for type(bufsize) != int.
>From what I can ascertain from the source, io.BytesIO.read() only expects an >int because this type is merged with long in Python3*. I also believe >io.BytesIO may have been backported and so this difference in the treatment of >int and long was not picked up. I have attached a test demonstrating the type failure, with comments for it's testing under Python3, where this evidently doesn't occur. It also compares results with io.BytesIO's predecessors, StringIO and cStringIO. I would attach a patch but I'm unsure of the general process, so here instead are relevant lines of interest from the 2.6.4 vanilla source: zipfile.py:447 ZipExtFile.bytes_read is assigned a long zipfile.py:594 a long is passed to a fileobj (such as io.BytesIO) _bytesio.c:222 the type of the argument to io.BytesIO.read() is checked to be an int ---------- components: Library (Lib) files: zipfile_testcase.py messages: 99260 nosy: anacrolix severity: normal status: open title: zipfile.ZipExtFile passes long to fileobj.read() type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file16217/zipfile_testcase.py _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7916> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
