B. Retain the full codecs module API, but reimplement relevant parts
in terms of the io module.
This solution would not break backward compatibility, or less than my
PEP. I didn't try to implement this solution. It should be possible for
StreamReader (-> TextIOWrapper), StreamWriter (-> TextIOWrapper) and
StreamReaderWriter (-> TextIOWrapper), but not for EncodedFile (by the
why, who use this horrible class? :-)).
I would prefer solution C to have only one obvious way to read-write
text files in Python 3(.4).
A 2to3 fixer that simply changes "codecs.open" to "open" is not
viable, as the function signatures are not compatible (the buffering
parameter appears in a different location):
codecs.open(): open(filename, mode='rb', encoding=None,
errors='strict', buffering=1)
3.x builtin open(): open(file, mode='r', buffering=-1,
encoding=None, errors=None, newline=None, closefd=True)
What? The prototypes are very close, you just to have to invert some
arguments. Why do you think that we cannot implement that?
Now, the backported io module does make it possible to write correct
code as far back as 2.6 that can be forward ported cleanly to 3.x
without requiring code modifications. However, it would be nice to
transparently upgrade code that uses codecs.open to the core IO
implementation in 3.x. For people new to Python, the parallel (and
currently deficient) alternative IO implementation also qualifies at
the very least as an attractive nuisance.
Use codecs.open() if you would like to support Python 3 and Python 2
older than 2.6.
If you don't care of Python 2.5, use directly the io module (you just
have to know that it is slow in Python 2.6).
Victor
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
