[I18n-sig] JapaneseCodecs 1.1 with ISO-2022-JP codec

[Martin v. Loewis]

> One question: is there a requirement that a codec must be able
> to deal with encodings (e.g. UTF-16LE) other than the intended
> encoding (e.g. EUC-JP)?  As of this writing, the Japanese codecs
> can only handle the only one intended encoding, and will raise
> an exception when a byte within an unexpected range appears in
> the input stream.

Not at all. Codecs are obtained by codec.lookup, so the codec classes
only need to support the encodings under which they are registered (or
rather those which their search function says they support).

> BTW, in the SourceForge Patch Manager there was a patch for
> fixing the problem exactly described in the quotation above:
> 
> http://sourceforge.net/patch/?func=detailpatch&patch_id=101477&group_id=5470
> 
> The sender of this patch was me (I did not have the SourceForge
> account when I posted it).

As Marc-Andre points out, this has a number of limitations, e.g. it
does assume LE, and does not support \r and other line-breaking
characters.

I really wonder why readline couldn't do buffering - for plain files,
it appears that this has to do with the file/stream position, but
StreamReaders don't support seek, anyway.

Regards,
Martin