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