Nadeem Vawda <nadeem.va...@gmail.com> added the comment: For 3.x, I think that ignoring non-string names is a reasonable fix. The docs for io.FileIO specify that its name attribute can be either a path or an integer file descriptor, and changing this doesn't seem to serve any purpose.
As for the case of 2.7's bogus "<fdopen>" name attribute, I'm not sure what the best course of action is. I agree that ideally we would want to get rid of the attribute altogether (for objects returned by fdopen), or change the semantics to those used by FileIO in 3.x, but making that sort of change in a bugfix release seems unwise. One alternative would be for GzipFile to specifically check whether a file object was returned by fdopen(), and if so ignore the fake name. I'm not sure how this could be accomplished, though - just checking for name == "<fdopen>" is too fragile for my liking, and I can't see any other obvious way of distinguishing objects created by fdopen() from those created by open(). > (another quick test shows that gzip in python 3.x can't output to a BytesIO > fileobj at all, it thinks it is readonly) Are you sure about this? I can't reproduce the problem. Running this script: import gzip, io b = io.BytesIO() with gzip.GzipFile(fileobj=b, mode="w") as g: g.write(b"asdf ghjk") print(b.getvalue()) b.seek(0) with gzip.GzipFile(fileobj=b, mode="r") as g: print(g.read()) I get the following output: b'\x1f\x8b\x08\x00\xe1\xa4\x14O\x02\xffK,NISH\xcf\xc8\xca\x06\x00P\xd2\x1cJ\t\x00\x00\x00' b'asdf ghjk' ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13781> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com