The name and the version of the curses library are needed for work around bugs in old versions or skip tests on platforms that provide broken curses library (like OpenBSD providing ncurses 5.7).

The curses and _curses modules provide the attribute "version" (= b'2.2'), but this is just a version of the module.

How can we get the ncurses version?

On Fedora 26, /usr/include/ncurses/curses.h contains:
---
/* These are defined only in curses.h, and are used for conditional compiles */
#define NCURSES_VERSION_MAJOR 6
#define NCURSES_VERSION_MINOR 0
#define NCURSES_VERSION_PATCH 20170212

/* This is defined in more than one ncurses header, for identification */
#undef  NCURSES_VERSION
#define NCURSES_VERSION "6.0"

/*
 * Identify the mouse encoding version.
 */
#define NCURSES_MOUSE_VERSION 2
---

You want to expose such versions? Do you know if there are "curses" implementations different than GNU ncurses?
https://www.gnu.org/software/ncurses/

I'm asking to know how other implementations expose their versions.

> The name and the version of the curses library are needed for work around bugs in old versions or skip tests on platforms that provide broken curses library (like OpenBSD providing ncurses 5.7).

If there are known issues depending on the ncurses version, it may help to export this version in the test.pythoninfo utility. Do you have an example of known bug? Do we already skip tests depending on the ncurses version?

Yes, this is what I meant. The version should be exposed as a tuple (major, minor, patch) or as a special named tuple. I don't know what to do with other implementations. NCURSES_VERSION_MAJOR is not a part of standard. One solution -- set the version to (0, 0, 0) for unknown implementations. Or expose ncurses version as optional ncurses_version, and expose versions for other known implementations with different names.

A known bug is issue15037. We still don't skip tests depending on the ncurses version because there is no easy way to determine the ncurses version in Python.

I suggest:

curses._NCURSES_VERSION_INFO = (6, 0, 20170212)
curses._NCURSES_VERSION = "6.0"
curses._NCURSES_MOUSE_VERSION = 2

Similar example, the readline module uses:

    PyModule_AddIntConstant(m, "_READLINE_VERSION", RL_READLINE_VERSION);
    PyModule_AddIntConstant(m, "_READLINE_RUNTIME_VERSION", rl_readline_version);
    PyModule_AddStringConstant(m, "_READLINE_LIBRARY_VERSION", rl_library_version);

readline has two famous implementations: GNU readline and editline. editline reuses GNU readline constants, but the string mentions "editline". Example on macOS El Capitain (test.pythoninfo output):

readline._READLINE_LIBRARY_VERSION: EditLine wrapper
readline._READLINE_RUNTIME_VERSION: 0x402
readline._READLINE_VERSION: 0x402

http://buildbot.python.org/all/builders/x86-64%20El%20Capitan%203.x/builds/871/steps/pythoninfo/logs/stdio

I'm not sure that it's useful to make versions public. I suggest to start with private versions, since we only plan to use them in tests right now.

pythoninfo seems like the right place.  It is publicly readable.  We just reserved the right to change it in any release as needed.  (This actually is useful to other users also as long as they know.) #15037 was originally filed for 3.4 and is currently marked for 3.6.  Backporting this to 3.6 will allow a 3.6 fix for #15037.

No need to backport this to 3.6. The test in 3.6 can be skipped on OpenBSD, independently from the ncurses version.

PR 4217 adds a named tuple curses.ncurses_version containing the three components of the ncurses library version: major, minor, and patch.

>>> curses.ncurses_version
curses.ncurses_version(major=6, minor=0, patch=20160625)

Other curses implementation don't provide a version programmically.

New changeset b232df9197a19e78d0e2a751e56e0e62547354ec by Serhiy Storchaka in branch 'master':
bpo-31680: Add curses.ncurses_version. (GH-4217)
https://github.com/python/cpython/commit/b232df9197a19e78d0e2a751e56e0e62547354ec