-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose curses library name and version on Python level #75861
Comments
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? I'm asking to know how other implementations expose their versions. |
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 bpo-15037. 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 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.) bpo-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 bpo-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. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: