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