Martin Panter added the comment:
So the problem seems to be that Python assumes Readline’s encoding is UTF-8,
but Readline actually uses ASCII (depending on locale variables). The code at
the start of the test is supposed to catch when add_history() calls
PyUnicode_EncodeLocale() and fails.
I don’t understand the details of UTF-8 vs locale on Android, but maybe we
could adjust the encode() and decode() implementations in Modules/readline.c,
to account for the Readline library’s idea of the locale encoding. Or maybe we
could adjust the temporary setlocale() calls in Modules/readline.c.
If you are happy to declare the Readline library is broken on Android, I now
think I would prefer to skip the test based on support.is_android, rather than
the previous patches. Otherwise, we risk masking genuine test failures on other
platforms. Something like:
@unittest.skipIf(is_android,
"Gnu Readline disagrees about the locale encoding on Android")
def test_nonascii(self):
try:
readline.add_history("\xEB\xEF")
...
When you run “LANG= bash”, it is only Bash and Readline that gets the C locale;
the terminal is unchanged. I presume the terminal inputs é as two UTF-8 bytes,
but Readline with the C locale is not aware of UTF-8, and assumes the two bytes
are two separate characters.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue28997>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
