On 1/11/19 5:28 PM, Kenneth Hoste wrote:
Dear Jakob,
On 18/12/2018 14:10, Jakob Schiøtz wrote:
Dear all,
One of my colleagues has a problem with the default Python build.
The curses module does not properly support unicode because the
Python executable is linked with libncurses instead of libncursesw.
Do you know if that is something that is easily fixable, or would
fixing this break something else?
Symptom:
~$ module load Python/3.6.6-foss-2018b
~$ python -c "import curses; curses.wrapper(lambda scr: scr.get_wch)"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File
"/home/modules/software/Python/3.6.6-foss-2018b/lib/python3.6/curses/__init__.py",
line 94, in wrapper
return func(stdscr, *args, **kwds)
File "<string>", line 1, in <lambda>
AttributeError: '_curses.window' object has no attribute 'get_wch'
On other machines (e.g. my Macbook), this does not produce an error.
Linking to libncurses.a is currently hardcoded in the Python
easyblock, so that would have to be changed definitely in one way or
another.
It seems like ncursesw can be seen as a drop-in replacement for
ncurses with better locale support, based on
https://invisible-island.net/ncurses/ncurses.faq.html#growing_features .
But it's unclear how to best handle this w.r.t. backward compatibility.
Do we change the Python easyblock to (always) prefer linking to
ncursesw if it's available, and use ncurses only as a fallback?
Or do we add a custom easyconfig parameter to specify preference of
ncursesw vs ncurses?
Or maybe something else?
I would guess that no one will want to use ncurses if ncursesw is
available. So, I'd say "prefer linking to ncursesw if it's available,
and use ncurses only as a fallback".
Jens Jørgen
regards,
Kenneth
