./Modules/_cursesmodule.c:279: error: syntax error before 'cchar_t'
/Users/sysadmin/build/v3.3.0a1/Modules/_cursesmodule.c: In function 'PyCurses_ConvertToCchar_t':
./Modules/_cursesmodule.c:289: error: 'obj' undeclared (first use in this function)/Users/sysadmin/build/v3.3.0a1/Modules/_cursesmodule.c:279: error: syntax error before 'cchar_t'

Note to self, this installer build builds its own version of ncurses. It may need adjusting for 3.3.

Is this issue still valid?

It was still valid as of 3.3.0a4.

And will you fix it for beta1, or do you think it can be done later?

BTW, what is the syntax error here?  I don't really see it...

New changeset 2035c5ad4239 by Ned Deily in branch 'default':
Issue #14225: Fix Unicode support for curses (#12567) on OS X:
http://hg.python.org/cpython/rev/2035c5ad4239

It turns out that the Unicode support for curses did not build correctly on OS X at all.  There were two issues:

1. On OS X, unlike many systems, does not supply separate libncurses and libncursesw in /usr/lib; same for libpanel/libpanelw. So the tests in setup.py based on the presence of the "w" libs failed, thus disabling the wide-char support in the extension modules even though the OS X libs supported it.  The tests in setup.py are now fixed to handle building on OS X with either the system libs or locally-supplied copies.

2. The 32-bit-only installer has historically built and supplied its own copy of libncursesw so that installer build did find a wide lib.  However, the wide code support within ncurses is conditional depending on _XOPEN_SOURCE_EXTENDED which is specifically not defined for OS X  (platform=='darwin') builds.  That caused the compile errors (things like cchar_t from the ncurses include files were not getting defined).  The solution for that is to supply _XOPEN_SOURCE_EXTENDED locally to the _curses* extension module builds.

Cool, thanks for the fix!

P.S. All is not perfect.  I initially missed re-running test_curses with the system ncurses library on OS X where ncurses is at 5.4 or with the 32-bit-installer which builds ncurses 5.5.  When I did, test_curses failed as described in Issue15037.  test_curses passes when Python is built with a MacPorts ncurses 5.9.  The best solution would be to update the installer builds to build and use the latest ncurses 5.9.  That may have to wait until after 3.3.0b1.

P.P.S. I've updated the OS X installers as of 3.3.0b2 to build and link with a local copy of ncurses 5.9 rather than older Apple-supplied ones.  test_curses now passes.