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

[Victor Stinner]

Le mardi 24 mai 2011 à 15:24 +1000, Nick Coghlan a écrit :
> 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?

Yes, it's trivial to implement codecs.open using:

def open(filename, mode='rb', encoding=None, errors='strict',
buffering=1):
    return builtins.open(filename, mode, buffering, 
                         encoding, errors, newline='')

But do you we really need two ways to open a file? Extract of import
this:
"There should be one-- and preferably only one --obvious way to do it."

Another example: Python 3.2 has subprocess.Popen, os.popen and
platform.popen to open a subprocess. platform.popen is now deprecated in
Python 3.3. Well, it's already better than Python 2.5 which has
os.popen(), os.popen2(), os.popen3(), os.popen4(), os.spawnl(),
os.spawnle(), os.spawnlp(), os.spawnlpe(), os.spawnv(), os.spawnve(),
os.spawnvp(), os.spawnvpe(), subprocess.Popen, platform.popen and maybe
others :-)

> How API compatible is TextIOWrapper with StreamReader/StreamWriter?

It's fully compatible.

> How hard would it to be change them to be adapters over the main IO
> machinery rather than independent classes?

I don't understand your proposition. We don't need StreamReader and
StreamWriter to open a stream as a file text, only incremental decoders
and encoders. Why do you want to keep them?

Victor