Author martin.panter
Recipients martin.panter, xdegaye
Date 2016-12-23.22:51:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1482533506.07.0.844813962534.issue28997@psf.upfronthosting.co.za>
In-reply-to
Content
The basic idea of your patch may be reasonable, but something is not right. Imagine the locale is something other than UTF-8. The input code will now contain mojibake print("\xC3\xAB"), although the decode() call will translate the result back to the expected "\xEB".

I suggest this 2nd version of the patch. I used io.TextIOWrapper to use the locale encoding, and incorporated the other test character "\xEF". I also changed the preliminary test to call input() instead of relying on the interactive interpreter, quiet mode, etc.

Just to clarify, is the problem that Python (correctly) assumes UTF-8 encoding on Android, but Readline does not unless you tweak the environment variable? I.e. is Readline assuming ASCII or something and ignoring the test characters? If so, it sounds like this may be a more general problem with Gnu tools and libraries on Android.
History
Date User Action Args
2016-12-23 22:51:46martin.pantersetrecipients: + martin.panter, xdegaye
2016-12-23 22:51:46martin.pantersetmessageid: <1482533506.07.0.844813962534.issue28997@psf.upfronthosting.co.za>
2016-12-23 22:51:46martin.panterlinkissue28997 messages
2016-12-23 22:51:45martin.pantercreate