Python 3.12 dropped ncurses wide char support on macOS, so for example curses.get_wch() is not available anymore.
I believe this was an unintended consequence of #94452, because the change is not documented anywhere. After that PR, HAVE_NCURSESW is never defined on Darwin. It looks like this bit of logic was not ported from setup.py to configure.ac:
Would it be interesting to encode some platform expectations in tests?
This regression went under the radar because test_unget_wch is skipped with @requires_curses_func('unget_wch'), among other reasons. Skipping makes sense in general. But in some build configurations (including macOS CI, macOS buildbots, and the official macOS installer) we know that we are building with ncurses, and unget_wch should exist.
Since this functionality is documented to be generally available, should a test assert that it actually is?
I need help with this then. What is a test supposed to test? We could say that wide char support should always be there on Darwin, but it could fail on builds that bring their own curses (or not).
@erlend-aasland : What kind of tests do you want to see here? AFAIK we generally don't test if expected platform features are present, other than some tests I've added when working on the Universal 2 port to ensure that weak linking works as expected.
Activity
ned-deily commented on Oct 29, 2023
@erlend-aasland
erlend-aasland commented on Oct 29, 2023
Yes, this is probably an unintended side effect. I can look into it tomorrow.
(cc. @corona10, if you are interested)
corona10 commented on Oct 29, 2023
Yeah I will take a look too
sorcio commented on Oct 30, 2023
Would it be interesting to encode some platform expectations in tests?
This regression went under the radar because test_unget_wch is skipped with @requires_curses_func('unget_wch'), among other reasons. Skipping makes sense in general. But in some build configurations (including macOS CI, macOS buildbots, and the official macOS installer) we know that we are building with ncurses, and unget_wch should exist.
Since this functionality is documented to be generally available, should a test assert that it actually is?
pythongh-111460: restore ncurses widechar support on macOS
sorcio commented on Nov 9, 2023
Maybe it was a one-character fix after all: #111878
(Note: if you are testing curses on macOS <14, you might need #111258 or a similar fix)
Should some test be added?
gh-111460: Restore ncurses widechar support on macOS (#111878)
pythongh-111460: Restore ncurses widechar support on macOS (pythonGH-…
[3.12] gh-111460: Restore ncurses widechar support on macOS (GH-111878)…
erlend-aasland commented on Nov 14, 2023
Can this be closed?
sorcio commented on Nov 14, 2023
@erlend-aasland if there is no need to test this, we're done here.
erlend-aasland commented on Nov 14, 2023
There's always a need for accompanying tests.
sorcio commented on Nov 19, 2023
I need help with this then. What is a test supposed to test? We could say that wide char support should always be there on Darwin, but it could fail on builds that bring their own curses (or not).
ronaldoussoren commented on Dec 5, 2023
@erlend-aasland : What kind of tests do you want to see here? AFAIK we generally don't test if expected platform features are present, other than some tests I've added when working on the Universal 2 port to ensure that weak linking works as expected.
erlend-aasland commented on Dec 5, 2023
I did not have anything in particular in mind. If there is no particular need, let's just close this.
pythongh-111460: Restore ncurses widechar support on macOS (python#11…
pythongh-111460: Restore ncurses widechar support on macOS (python#11…