This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nadeem.vawda
Recipients amaury.forgeotdarc, daniel.urban, eric.araujo, nadeem.vawda, pitrou, rasmusory, rhettinger, serhiy.storchaka
Date 2012-06-26.21:02:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340744541.58.0.93964324663.issue12559@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2012-06-26 21:02:21nadeem.vawdasetrecipients: + nadeem.vawda, rhettinger, amaury.forgeotdarc, pitrou, eric.araujo, daniel.urban, rasmusory, serhiy.storchaka
2012-06-26 21:02:21nadeem.vawdasetmessageid: <1340744541.58.0.93964324663.issue12559@psf.upfronthosting.co.za>
2012-06-26 21:02:20nadeem.vawdalinkissue12559 messages
2012-06-26 21:02:19nadeem.vawdacreate