bpo-36982: Add support for extended color functions in ncurses 6.1 #13534
Conversation
using the extended color functions in ncurses 6.1 when available. color_content color_number init_color init_pair
to make them simpler and more maintainable
so use #if instead of #ifdef.
to indicate whether extended colors are suported by the underlying ncurses library.
that is the name of the Python module)
|
I resolved the conflicts in Doc/whatsnew/3.8.rst |
|
Is there a reason for dropping argument clinic support by this PR? |
|
I removed clinic from these functions so that _NCURSES_EXTENDED_COLOR_FUNCS could be used to specify short or int for the function parameters, as well as other macros for to select the parameter bounds checking limits. Clinic choked on the macro names, which is understandable. Writing this reply, it occured to me how to refactor the code to use clinic. I will do so to make it consistent with the other funcs. |
|
I refactored the code to use clinic. |
There was a problem hiding this comment.
Tested locally by ./python -m test -v -u curses test_curses
======================================================================
ERROR: test_colors_funcs (test.test_curses.TestCurses)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/andrew/projects/cpython/Lib/test/test_curses.py", line 286, in test_colors_funcs
curses.pair_content(curses.COLOR_PAIRS - 1)
_curses.error: Argument 1 was out of range. (1..COLOR_PAIRS-1)
----------------------------------------------------------------------
Ran 28 tests in 0.360s
FAILED (errors=1)
test test_curses failed
test_curses failed
== Tests result: FAILURE ==
1 test failed:
test_curses
Total duration: 441 ms
Tests result: FAILURE
Note, travis/azure don't have curses resource enabled, that's why tests are green
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
|
@websurfer5, if you're interested in continuing on this PR by resolving the merge conflict and addressing the code review comments, we can close the other PR which was opened based on this one. If you'd rather for that PR to continue, then feel free to close this one. |
|
At this point, I think #17536 includes everything from this PR (except for the doc update which I've pinged on the other PR) and has been gone through several code review updates. @websurfer5 is being credited on that PR as well. Let's just close this one. Thanks, @websurfer5 for making this happen. |
ncurses 6.1 adds extended color functions to support terminals with 256 colors (e.g. xterm-256color). The extended functions use color-pair values that are signed integers because the existing functions only use signed short integer values that are too small to support the 65,536 color-pair values needed for a 256-color terminal.
The new extended color functions are used transparently by curses.color_content(), curses.init_color(), curses.init_pair(), and curses.pair_content() when available, and the original functions are used when they aren't. The module functions validate their parameters as signed integers when using the new extended functions and as signed short integers when using the original library functions to match the underlying ncurses function parameters. The original behavior remains unchanged when Python is built with a curses library that does not contain the new extended color functions.
A new function, curses.has_extended_color_support(), indicates whether extended color support is provided by the underlying ncurses library.
This PR also fixes issue #36630.
https://bugs.python.org/issue36982