[issue20420] BufferedIncrementalEncoder violates IncrementalEncoder interface

Change by Irit Katriel : -- components: +Library (Lib) versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.3, Python 3.4 ___ Python tracker ___

[issue20420] BufferedIncrementalEncoder violates IncrementalEncoder interface

Martin Panter added the comment: For what it’s worth, both io.TextIOWrapper and _pyio.TextIOWrapper appear to only ever call IncrementalEncoder.setstate(0). And the newline _decoder_ is not relevant because it doesn’t use any _encoder_. -- nosy: +vadmium

[issue20420] BufferedIncrementalEncoder violates IncrementalEncoder interface

Serhiy Storchaka added the comment: IncrementalNewlineDecoder requires that decoder state is integer (C implementation requires at most 63-bit unsigned integer). TextIOWrapper requires that decoder state is at most 64-bit unsigned integer (only 63-bit if universal newlines is enabled).

[issue20420] BufferedIncrementalEncoder violates IncrementalEncoder interface

Walter Dörwald added the comment: I dug up an ancient email about that subject: However, I've discovered that BufferedIncrementalEncoder.getstate() doesn't match the specification (i.e. it returns the buffer, not an int). However this class is unused (and probably useless, because it

[issue20420] BufferedIncrementalEncoder violates IncrementalEncoder interface

New submission from Serhiy Storchaka: The documentation of IncrementalEncoder.getstate() says: Return the current state of the encoder which must be an integer. The implementation should make sure that 0 is the most common state. (States that are more complicated than integers can be