Le mardi 24 mai 2011 à 10:03 +0200, M.-A. Lemburg a écrit : > Please read PEP 100 regarding StreamReader and StreamWriter. > Those codecs parts were explicitly designed to be stateful, > unlike the stateless encoder/decoder methods.
Yes, it is possible to implement stateful StreamReader and StreamWriter classes and we have such codecs (I gave the example of UTF-16), but the state is not exposed (getstate / setstate), and so it's not possible to write generic code to handle the codec state in the base StreamReader and StreamWriter classes. io.TextIOWrapper requires encoder.setstate(0) for example. > Each codec can, however, implement variants which are optimized > for the specific encoding or intercept certain stream methods > to add functionality or improve the encoding/decoding > performance. Can you give me some examples? > TextIOWrapper and StreamReaderWriter are merely wrappers > around streams that make use of the codecs. They don't > provide any codec logic themselves. That's the conceptual > difference. > ... > StreamReader and StreamWriters ... work efficiently and > directly on streams rather than buffers. StreamReader, StreamWriter, TextIOWrapper and StreamReaderWriter all have a file-like API: tell(), seek(), read(), readline(), write(), etc. The implementation is maybe different, but the API is just the same, and so the usecases are just the same. I don't see in which case I should use StreamReader or StreamWriter instead TextIOWrapper. I thought that TextIOWrapper is specific to files on disk, but TextIOWrapper is already used for other usages like sockets. > Here's my reply from the ticket regarding using incremental > encoders/decoders for the StreamReader/Writer parts of the > codec set of APIs: > > """ > The point about having them use incremental codecs for encoding and > decoding is a good one and would > need to be investigated. If possible, we could use incremental > encoders/decoders for the standard > StreamReader/Writer base classes or add new > IncrementalStreamReader/Writer classes which then use > the IncrementalEncode/Decoder per default. Why do you want to write a duplicate feature? TextIOWrapper is already here, it's working and widely used. I am working on codec issues (like CJK encodings, see #12100, #12057, #12016) and I would like to remove StreamReader and StreamWriter to have *less* code to maintain. If you want to add more code, will be available to maintain it? It looks like you are busy, some people (not me ;-)) are still waiting .transform()/.untransform()! 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