[Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader

[Victor Stinner]

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