Ncurses Extended Color Pairs incorrectly display as copies of lower 256 color pairs

[cmang]

Bug report

Bug description:

When using ncurses extended color pairs, introduced in Python 3.10 in PR #17536 and issue #81163, the color pairs past 256 don't seem to work. When accessed, pairs 256+ repeat the behavior of pairs 0-255 instead of the colors set by curses.init_pair().

In my use case, curses.has_extended_color_support() == True and curses.COLORS == 256.

I can use curses.init_pair() to initialize color pairs past 255. It lets me set them without any error. But when I go to display the colors, color pair 256 displays the same as color pair 0, 257 displays the same as 1, and so on.

I created a small test program to reproduce the issue by initializing, displaying, and letting you scroll through the extended color pairs, examining pairs 0-65536: https://gist.github.com/cmang/7d366f677cd067c00e58a9d9c97141c5

The test program initializes 256 * 256 (65536) color pairs, using every FG and BG combination for FG and BG colors 0-255. It then lets you use the left/right arrow keys to scroll through the pairs. It requires an xterm-256color capable terminal.

In the following screenshot, the test program shows each color pair number in its given color and you can see that the pairs repeat. The expected behavior is that pairs 256-512 should have a different background color set (red), as should the next 256 pairs (green), etc.

Edit: If you get an error running the test program, make your terminal larger.

@hpjansson @websurfer5

Thanks!

CPython versions tested on:

3.10, 3.11, 3.12

Operating systems tested on:

Linux, macOS

[hpjansson]

The addstr and addch functions take an attribute value, but attributes can only store a color pair in the range 0..255. COLOR_PAIR() applies a bitmask so it can be combined with other attributes. I think we need new API to allow users to pass in the color pair separately and use wattr_set() internally instead of the legacy wattrset(). Ref. attr(3NCURSES).