A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2011-May/111596.html below:

[Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader

[Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReaderNick Coghlan ncoghlan at gmail.com
Tue May 24 07:24:20 CEST 2011
On Tue, May 24, 2011 at 10:08 AM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> It's trivial to replace a call to codecs.open() by a call to open(),
> because the two API are very close. The main different is that
> codecs.open() doesn't support universal newline, so you have to use
> open(..., newline='') to keep the same behaviour (keep newlines
> unchanged). This task can be done by 2to3. But I suppose that most
> people will be happy with the universal newline mode.

Is there any reason that codecs.open() can't become a thin wrapper
around builtin open in 3.3?

> I don't see which usecase is not covered by TextIOWrapper. But I know
> some cases which are not supported by StreamReader/StreamWriter.

How API compatible is TextIOWrapper with StreamReader/StreamWriter?
How hard would it to be change them to be adapters over the main IO
machinery rather than independent classes?

Rather than deprecating them, that seems like a more profitable
direction to take them.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4