homepage

ncurses6 turned on NCURSES_OPAQUE, so now you have to use some helper functions instead of accessing the structs directly. This _should_ be compatible with ncurses5 though I didn't test it.
Original patch is from openSUSE.

Any patch review/comment ?

configure.ac directly uses w->_flags in a check. It looks that this check always fails with ncurses6.

Thats not an issue for ncurses because Include/py_curses.h does:
 #ifdef HAVE_NCURSES_H
 /* configure was checking <curses.h>, but we will
 use <ncurses.h>, which has all these features. */
 #ifndef WINDOW_HAS_FLAGS
 #define WINDOW_HAS_FLAGS 1
 #endif
 #ifndef MVWDELCH_IS_EXPRESSION
 #define MVWDELCH_IS_EXPRESSION 1
 #endif
 #endif
So it overrides WINDOW_HAS_FLAGS for ncurses case.

ping?

I suspect that the patch can break build with non-ncurses implementations or with old ncurses (when is_pad() was added?). Needed more direct feature check.

is_pad is added in ncurses 5.7-20090906 [1]. At least Mac OS X still ships ancient ncurses 5.7-20081102 [2], so an check in configure.ac is necessary. I'm trying it out.
[1] http://invisible-island.net/ncurses/NEWS.html#t20090906
[2] http://opensource.apple.com//source/ncurses/ncurses-46/ncurses/NEWS 

Mark, do you have relation to this?

I tried to build curses module on Cygwin (Vista x86) using #25720 patch. And it has been succeeded.
When test_curses ran without skip condition, it was same result as msg278060 (#28190).
I found out build success reasons for cases of applying patch:
#25720 -- implementation of WINDOW is opaque (*but* WINDOW_HAS_FLAGS is defined at Include/py_curses.h:61 ). However, curses module build went well to cover the _flags field from source code by is_pad.
#14598 -- implementation of WINDOW is not opaque (WINDOWS_HAS_FLAGS is defined at configure script). Therefore, curses module build went well because WINDOW has the _flags field.
#28190 -- implementation of WINDOW is opaque (WINDOW_HAS_FLAGS isn't defined: py_curses.h has been cleaned by patch). Hence, curses module build went well to remove the _flags field from source code at preprocessing.
All case tests on Cygwin have failed at unget_wch.

> Mark, do you have relation to this?
Sorry, no. Whatever ncurses knowledge I may once have had has long since vanished.

I updated the patch that add configuration check for is_pad. the is_pad is wrapped into py_is_pad at Modules/_cursesmodule.c:932 by either of three ways.
Case one -- is_pad is found: Define the macro that is simple wrapping.
Case two -- is_pad is not found, however WINDOW has _flags field: Define the macro using _flags field.
Case three -- is_pad is not found, and WINDOW doesn't have _flags field: Define the macro that is always preprocessed to FALSE.
I succeeded to build curses module on Cygwin (Vista x86) using this patch.
This patch doesn't include that undo fixes for specific platforms.

@masamoto thank you!

Added a comment on Rietveld.

Thanks masamoto! There's another minor issue about this patch: if there's no curses.h (ncurses built with --without-curses-h), the detection always fails.

Added comment in review.
Yen, I tried to build without curses.h file (overwrite to ncurses.h). It was failed on checking header. Hence, I confirmed curses headers on Cygwin and Ubuntu.
I found out that curses.h includes the directive "#include <unctrl.h>". And unctrl.h has "#include <curses.h>". Therefore, I think that some platforms require curses.h.
Would you confirm your platform curses library?

headers.sh in ncurses changes "#include <curses.h>" to the actual path. For example here's a line in my unctrl.h:
#include <ncursesw/ncurses.h>

Thank you for confirming, Yen :)
In this case, It seems necessary that resolves headers. I think missing headers issue maybe solve by #28190. I wrote a join test patch for #28190 and #25720.
Would you be able to resolve headers using this?

Thanks, building is fine here.
By the way, testing is broken due to other bugs (/tmp not available on Android). It's unrelated and I'll open a new issue for that.

What's the status on this? Can you please create a pull request on Github so we can continue there?

Hi, I finished various things and tackle the issue again, I opened PR 1689 at last.
Changes from previous patch:
* If ncurses doesn't have both is_pad function and _flags field of WINDOW, NCURSES_OPAQUE is defined as zero to make WINDOW to non-opaque type before including ncurses.h.
* The conditional compile on function definition are kept, it replaces WINDOW_HAS_FLAGS with py_is_pad macro itself.
* Unindent the blocks that places after section of the conditional compile on function definition.

Ping. I updated PR a bit: macOS is joined to new compile condition and remove platform-specific condition.

I opened PR 4164 to improve the is_pad configure check and previous PR was closed.

I'll try to test this on NetBSD after fixing curses on NetBSD. It uses a different implementation of curses which don't support is_pad.

New changeset 8bc7d63560024681dce9f40445f2877b2987e92c by Serhiy Storchaka (Masayuki Yamamoto) in branch 'master':
bpo-25720: Fix the method for checking pad state of curses WINDOW (#4164)
https://github.com/python/cpython/commit/8bc7d63560024681dce9f40445f2877b2987e92c

New changeset ff6ae4de3874f4922a5883f08bb661c93834b060 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-25720: Fix the method for checking pad state of curses WINDOW (GH-4164) (#4212)
https://github.com/python/cpython/commit/ff6ae4de3874f4922a5883f08bb661c93834b060

New changeset 6ba0b583d6785a256b17d27431908d67015eeeb6 by Serhiy Storchaka (Miss Islington (bot)) in branch '2.7':
bpo-25720: Fix the method for checking pad state of curses WINDOW (GH-4164) (#4213)
https://github.com/python/cpython/commit/6ba0b583d6785a256b17d27431908d67015eeeb6

Thank you for your contribution Masayuki!