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 mjacob
Recipients docs@python, mjacob
Date 2020-06-23.15:26:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1592926017.53.0.619449435613.issue41091@roundup.psfhosted.org>
In-reply-to
Content
The documentation for the curses module (https://docs.python.org/3.9/library/curses.html) has the following note:

> Since version 5.4, the ncurses library decides how to interpret non-ASCII data using the nl_langinfo function. That means that you have to call locale.setlocale() in the application and encode Unicode strings using one of the system’s available encodings. This example uses the system’s default encoding:
> 
> import locale
> locale.setlocale(locale.LC_ALL, '')
> code = locale.getpreferredencoding()
> 
> Then use code as the encoding for str.encode() calls.

The recommendation to call `locale.setlocale(locale.LC_ALL, '')` is problematic as it initializes all locale categories to the user settings, which might be unintended and is not necessary for curses to work correctly. Initializing LC_CTYPE is sufficient for nl_langinfo() to return the correct encoding. Current versions of Python (*) initialize LC_CTYPE at interpreter startup. Therefore calling locale.setlocale() should not be necessary at all.

The curses module automatically encodes strings. Therefore the recommendation to manually encode strings is outdated.

(*) It seems to be the case since 177d921c8c03d30daa32994362023f777624b10d. Why was is not previously done on Python 2 and on Python 3 on Windows?
History
Date User Action Args
2020-06-23 15:26:57mjacobsetrecipients: + mjacob, docs@python
2020-06-23 15:26:57mjacobsetmessageid: <1592926017.53.0.619449435613.issue41091@roundup.psfhosted.org>
2020-06-23 15:26:57mjacoblinkissue41091 messages
2020-06-23 15:26:57mjacobcreate