[issue12559] gzip.open() needs an optional encoding argument

Nadeem Vawda 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.


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 <report at bugs.python.org>
<http://bugs.python.org/issue12559>
_______________________________________


More information about the Python-bugs-list mailing list