test_curses fails for me by default (running on Fedora 35 in KDE's Konsole):

[ncoghlan@thechalk cpython]$ echo $TERM
xterm-256color
[ncoghlan@thechalk cpython]$ ./python -m test -u curses test_curses
0:00:00 load avg: 0.88 Run tests sequentially
0:00:00 load avg: 0.88 [1/1] test_curses
test test_curses failed -- Traceback (most recent call last):
  File "/home/ncoghlan/devel/cpython/Lib/test/test_curses.py", line 48, in wrapped
    test(self, *args, **kwargs)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ncoghlan/devel/cpython/Lib/test/test_curses.py", line 993, in test_use_default_colors
    self.assertIn(old, [(curses.COLOR_WHITE, curses.COLOR_BLACK), (-1, -1), (0, 0)])
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: (15, 0) not found in [(7, 0), (-1, -1), (0, 0)]

test_curses failed (1 failure)

== Tests result: FAILURE ==

1 test failed:
    test_curses

Total duration: 466 ms
Tests result: FAILURE

The active terminal info indicates that the default text colour is indeed bright white (assuming I'm reading the infocmp output correctly), so it feels like (15, 0) is just missing from the set of permissible "old" colour pairs in the test case:

[ncoghlan@thechalk cpython]$ infocmp -L | grep initialize_color
        initialize_color=\E]4;%p1%d;rgb\072%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\,

I am surprised. I use Konsole too, and the TERM value and the infocmp output are the same for me.

can we reliably query for what the default is and add that to the expectations? or just skip the test if the defaults don't match our expectations (less ideal)?

if those are a challenge to do reliably - adding 15, 0 to the expected set may be the most practical.

Same issue with Konsole on openSUSE 15.3 while compiling Python 3.9.14 and 3.10.7

`TERM=xterm-256color
test_use_default_colors (test.test_curses.TestCurses) ...
FAIL

======================================================================
FAIL: test_use_default_colors (test.test_curses.TestCurses)

Traceback (most recent call last):
File "/home/krel/dev/Python-3.9.14/Lib/test/test_curses.py", line 46, in wrapped
test(self, *args, **kwargs)
File "/home/krel/dev/Python-3.9.14/Lib/test/test_curses.py", line 991, in test_use_default_colors
self.assertIn(old, [(curses.COLOR_WHITE, curses.COLOR_BLACK), (-1, -1), (0, 0)])
AssertionError: (15, 0) not found in [(7, 0), (-1, -1), (0, 0)]

Ran 1 test in 0.003s

FAILED (failures=1)
test test_curses failed`

Same issue with Konsole on Fedora 38:

Re-running test_curses in verbose mode (matching: test_use_default_colors)
TERM=xterm-256color
test_use_default_colors (test.test_curses.TestCurses.test_use_default_colors) ... 
======================================================================
FAIL: test_use_default_colors (test.test_curses.TestCurses.test_use_default_colors)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dandv/downloads/Python-3.12.3/Lib/test/test_curses.py", line 49, in wrapped
    test(self, *args, **kwargs)
  File "/home/dandv/downloads/Python-3.12.3/Lib/test/test_curses.py", line 999, in test_use_default_colors
    self.assertIn(old, [(curses.COLOR_WHITE, curses.COLOR_BLACK), (-1, -1), (0, 0)])
AssertionError: (15, 0) not found in [(7, 0), (-1, -1), (0, 0)]

I created two PRs, one that skips this check, and aonther that adds (15, 0) as a valid pair. I don't know how easy and how likely there would be users that could have their own custom terminfo possibly with different initialize_color values.

I've added the (15,0) pair so I think we can close this one. Let's re-open it other users have different issues and at this time we'll decide whether to skip the check or try to deduce more reliably the supported values.