This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients John Helour, lemburg, loewis, mdk, serhiy.storchaka, vstinner, xiang.zhang
Date 2016-11-14.13:11:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On 14.11.2016 13:03, STINNER Victor wrote:
> STINNER Victor added the comment:
>> # from utf-8 to iso6937
>> def iso6937_encode(input,errors,encoding_map):
> Wait, is this code for Python 3? Decode from UTF-8 and encode to ISO-6937 in the same function seems strange to me.

The patch shows the file as UTF-8. In reality, it is decoding from
Unicode strings.

> I expected that the codec only implements two functions: encode text (unicode) to ISO-6937 (bytes), decode bytes from ISO-6937 to text.
> Since the encoding is non trivial (multibyte), if we decide to add it, I suggest to require unit tests. I would like to see unit tests on multibyte strings, to check how the error handler is handled.


> In general, I would prefer to not embed too many codecs in Python, it has a little cost to maintain these codecs.
> My rule is more to only added encodings used (in practice) as locale encodings.

This encoding is used in EPG data of various DVB television
formats. As such it is in active use (even though it is very old).

I think "active use" is a better approach to restricting
ourselves to only locale encodings, since the latter are
slowly converging towards UTF-8 :-)

BTW: Once a charmap style codec is written, there is little
change, so the maintenance is minimal. Codecs which include
more active logic such as this one are different, of course,
and therefore may potentially add more maintenance burden.
Date User Action Args
2016-11-14 13:11:10lemburgsetrecipients: + lemburg, loewis, vstinner, serhiy.storchaka, xiang.zhang, John Helour, mdk
2016-11-14 13:11:10lemburglinkissue24339 messages
2016-11-14 13:11:09lemburgcreate