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 lemburg, msapiro
Date 2021-11-29.11:30:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1638185401.05.0.310709504884.issue45921@roundup.psfhosted.org>
In-reply-to
Content
Even though these are IANA recognized encodings, we need to apply he same logic as we do for all new encodings, which essentially boils down to: Are these encoding in wider spread use today ?

Reading through the RFC 1556, it seems that the added -i or -e are just indications for applications on how to interpret BIDI information: either implicit by looking at the order of characters in the stream or explicit via control characters embedded in the stream. They are not new encodings, with new mappings.

If that's a correct interpretation, we could add those as aliases for the non-annotated encodings.

After more than 20 years with Unicode support in Python and the world moving towards UTF-8, I have become fairly reluctant towards adding more encoding support to Python.

If people are still using unsupported encodings, it's probably better to point them to other dedicated tools for converting text to UTF-8, e.g. iconv, than extending the pretty extensive support we already have in Python.
History
Date User Action Args
2021-11-29 11:30:01lemburgsetrecipients: + lemburg, msapiro
2021-11-29 11:30:01lemburgsetmessageid: <1638185401.05.0.310709504884.issue45921@roundup.psfhosted.org>
2021-11-29 11:30:01lemburglinkissue45921 messages
2021-11-29 11:30:00lemburgcreate