> 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
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