[issue12559] gzip.open() needs an optional encoding argument
report at bugs.python.org
Tue Jun 26 23:02:21 CEST 2012
Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:
I already fixed this without knowing about this issue; see 55202ca694d7.
> 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.
> 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
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.4
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list