Mac version of Python doesn't support UTF-8 in curses module? [Solved]

Question

Hi,

I'm trying to display a lot of unicode text in my curses application. My development machine is MacOSx 10.6 and I use the default python shipped with Apple.

Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin

When I added unicode text to the screen, the screen all messed up. I tried to Google for solution and other people has suggested to link the _curses module with libncursesw library instead of libncurse library.

I checked my path and I found (see below) in /opt/local/lib

libncurses++.a
libncurses++w.a
libncurses.5.dylib
libncurses.a
libncurses.dylib
libncursesw.5.dylib
libncursesw.a
libncursesw.dylib

How do I check which library my curses module linked to, and how can I link against other library? Is it possible to do it without recompile my Python?

---

This is kind of embarrassed, but I figure the solution to print unicode properly in my environment. I think at some point time I did install curses libraries from Macports and forgot I have it already.

The problem that the text did not display the first time is because I need to set the locale within my python program. I thought the locale setting would inherit from the shell I'm running, but simply added two lines of code fixed my problem:

import locale
locale.setlocale(locale.LC_ALL,"")

Though, it's good to know where the python external library lives and how to check them. Thanks for the answer below.

Answer 1

The Apple-supplied Python 2.6 shipped with OS X 10.6 resides here:

$ cd /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload
$ otool -L _curses*
_curses.so:
    /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)
_curses_panel.so:
    /usr/lib/libpanel.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
    /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)

It would be a very bad idea to try to modify anything in /System/Library as that could break OS X and/or be wiped out by a system update. If you need to relink, build your own Python from scratch or start with Homebrew, MacPorts, or Fink.

EDIT:

It appears that the current MacPorts Python 2.6 install uses libncursesw so installing it may be the simplest solution:

$ cd /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/
$ otool -L _curses*
_curses.so:
    /opt/local/lib/libncursesw.5.dylib (compatibility version 5.0.0, current version 5.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
_curses_panel.so:
    /opt/local/lib/libpanelw.5.dylib (compatibility version 5.0.0, current version 5.0.0)
    /opt/local/lib/libncursesw.5.dylib (compatibility version 5.0.0, current version 5.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

Answer 2

To check which other .sos a .so uses, use otool -L -- for example:

$ otool -L /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_curses.so
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_curses.so:
    /Library/Frameworks/Python.framework/Versions/2.6/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10)

This is what I have on my Python 2.6.4 install on OSX 10.5 -- since you're using Apple's own Python on 10.6, the exact location of your _curses.so will be different, just do

$ python
>>> import _curses
>>> _curses.__file__

to see exactly where the _curses.so of interest in, then call otool -L on it.

Replacing a .so on the system-installed Python seems fraught with danger to me -- you could break something and end up having to reinstall the OS, etc. Why not install a Python download from python.org instead?

Get both the .dmg and the sources for the most recent release of 2.6 (unless you're so adventurous you want to try a release candidate 2.7;-), then you can install the .dmg (it will go to /usr/local, not overwriting the system Python; set your PATH appropriately in your .bashrc or wherever to have /usr/local/bin in your PATH ahead of /usr/bin), then, if your problem persists, you can rebuild from sources with whatever options you want, and replace the specific _curses.so in the local install, without disturbing the system directory at all (seems most prudent to me...).