Le 07/07/2011 10:07, M.-A. Lemburg a écrit : > The PEP's arguments for deprecating two essential codec design > components are very one sided, by comparing "issues" to "features". Yes, please help me to write an unbiased PEP. I don't know which tool is more appropriate to write a PEP with many authors. Can I upload it to the peps repository? According to the PEP 1, only a PEP editor can do that. > Please add all the comments I've made on the subject to the PEP. I tried to incorporate all of your comments, but because the discussion on the bug tracker and on python-dev was long, I missed maybe some (important) points. Sorry about that, and please tell me which points should be added to the PEP. > The most important one missing is the fact and major difference > that TextIOWrapper does not work on a per codec basis, but > only on a per stream basis. Yeah, it's not clear in the PEP, I should detail this point. > By removing the StreamReader and StreamWriter API parts of the > codec design, you essentially make it impossible to add > per codec variations and optimizations that require full access > to the stream interface. > > A mentioned before, many improvements are possible and lots of those > can build on TextIOWrapper and the incremental codec parts. I wrote that in the "Possible improvements of StreamReader and StreamWriter" section: "A codec can implement variants which are optimized for the specific encoding ..." and "It would be possible to change StreamReader and StreamWriter to make them use IncrementalDecoder and IncrementalEncoder." > For the issues you mention in the PEP, please open tickets > or add ticket references to the PEP. Ok, I will do that. There are other Stream* issues, a recent example: http://bugs.python.org/issue12508 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