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 vstinner
Recipients Arfrever, doko, ezio.melotti, iritkatriel, martin.panter, nadeem.vawda, petri.lehtinen, python-dev, serhiy.storchaka, vstinner
Date 2022-01-17.12:23:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1642422228.69.0.015951523366.issue13886@roundup.psfhosted.org>
In-reply-to
Content
rl-locale.diff changes the readline implementation of the PyOS_Readline() to set LC_CTYPE locale to "C": setlocale(LC_CTYPE, "C"), rather to the user preferred locale: setlocale(LC_CTYPE, ""). IMO it's a bad idea. Python made great progress in Unicode support, readline has a good Unicode support, and in most cases, it just works like a charm. This change looks a hack just to get these 2 specific tests to pass, but it breaks any other usage of readline.

rl-test.diff skips the test if the readline module can be imported, and it always import the readline module. It's different than that GH-30631 which only checks if the readline module is currently imported: my change doesn't import readline in test_builtin.

"input-readline*.patch" patches and GH-7133 spawn a fresh Python process to make sure that the readline is not imported or to import readline explicitly. They are better than my fix, but they are more complicated. It seems likle these changes also fix test_input_tty_non_ascii() but I don't understand how.
History
Date User Action Args
2022-01-17 12:23:48vstinnersetrecipients: + vstinner, doko, nadeem.vawda, ezio.melotti, Arfrever, python-dev, petri.lehtinen, martin.panter, serhiy.storchaka, iritkatriel
2022-01-17 12:23:48vstinnersetmessageid: <1642422228.69.0.015951523366.issue13886@roundup.psfhosted.org>
2022-01-17 12:23:48vstinnerlinkissue13886 messages
2022-01-17 12:23:48vstinnercreate