Nadeem Vawda <nadeem.va...@gmail.com> added the comment: I already fixed this without knowing about this issue; see 55202ca694d7.
storchaka: > Why not use io.TextWrapper? I think it is the right answer for this issue. The proposed patch (and the code I committed) *do* use TextIOWrapper. Unless you mean that callers should create the TextIOWrapper themselves. This is certainly possible, but quite inconvenient for something that is conceptually simple, and not difficult to implement. amaury.forgeotdarc: > There remains a difference between open() and gzip.open(): > open(filename, 'r', encoding=None) is a text file (with a default encoding), > gzip.open() with the same arguments returns a binary file. The committed code unfortunately still has gzip.open(filename, "r") returning a binary file. This is something that cannot be fixed without breaking backward compatibility. However, it does provide a way to open a text file with the system's default encoding (encoding=None, or no encoding argument specified). To do this, you can use the "rt"/"wt"/"at" modes, just like with builtins.open(). Of course, this also works if you do specify an encoding explicitly. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12559> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
