[Python-Dev] Unicode support of the curses module in Python 3.3
victor.stinner at gmail.com
Sat Sep 1 15:44:23 CEST 2012
I changed many functions of the curses module in Python 3.3 to improve
its Unicode support:
- new functions: curses.unget_wch() and window.get_wch()
- new attribute: window.encoding
- the default encoding is now the locale encoding instead of UTF-8
- use the C functions *_wch() and *wstr() when available instead of
*ch() and *str() functions. For example, the Python function addstr()
calls waddwstr() and addch(str) calls wadd_wch() (addch(int) and
addch(bytes) are still calling waddch())
Most new features related to Unicode now depends if the Python curses
module is linked to the C libncursesw library or not... and the Python
module is not linked to libncursesw if the libreadline library is
linked to libncurses module. How the readline library is linked to
libncurses/libncursesw is not a new problem but it may become more
annoying than before. I hope that most Linux distro are/will link
readline to libncursesw.
For example, if the Python curses module is not linked to libncursesw,
get_wch() is not available and addch("é") raises an OverflowError if
the locale encoding is UTF-8 (because "é".encode("utf-8") is longer
than 1 byte).
I introduced two bugs: get_wch() didn't support keycodes (like
curses.KEY_UP) and addch() didn't work anymore with special characters
like curses.ACS_HLINE. These issues are referenced as #15785 and
#14223 in the bug tracker, and I pushed fixes: c58789634d22 and
27b5bd5f0e4c. I hope that Georg will accept them in Python 3.3 final!
I didn't find these bugs myself because I only used dummy scripts to
test my changes. Does anyone know "real world" applications using the
curses module and supporting Python 3? Can you please test them with
non-ASCII characters and the last development version of Python 3.3?
So please try to test the curses module before Python 3.3 final with
your favorite application!
More information about the Python-Dev