@corona10, would you mind doing a review of this?

@vstinner, would you mind taking a look at this. After this cleanup, I think we can close bpo-41861.

Seems like the Travis CI is stuck…

PyMemberDef not part of the stable API

structmember.h is part of the limited C API. If it should not, I suggest to first exclude it from the limited C API, before changing _sqlite3 header files.

PyMemberDef not part of the stable API

structmember.h is part of the limited C API. If it should not, I suggest to first exclude it from the limited C API, before changing _sqlite3 header files.

If it was, it would be sufficient to include Python.h, no?

I'm not sure why some header files like frameobject.h are not included by Python.h. Not being included by Python.h doesn't mean excluded from the limited C API. Or maybe I misunderstood something.

cc @serhiy-storchaka

I'm not sure why some header files like frameobject.h are not included by Python.h. Not being included by Python.h doesn't mean excluded from the limited C API. Or maybe I misunderstood something.

From PEP 384: "Applications shall only include the header file Python.h (before including any system headers), or, optionally, include pyconfig.h, and then Python.h."

I was under the impression that the "stable C API" and the "limited C API" was the same thing, however, that might not be the case?

PyMemberDef not part of the stable API

structmember.h is part of the limited C API. If it should not, I suggest to first exclude it from the limited C API, before changing _sqlite3 header files.

I think that the "not part of the stable API" comment was a reference to bpo-2897. According to PEP 384, PyMemberDef is indeed a part of the stable (limited?) C API, however PyMemberDef is defined in structmember.h, and PEP 384 states that you're allowed to include Python.h only. Referenced in the bpo, there's a (huge) PR (#20462) that deprecates structmember.h and moves its content to descrobject.h.

The current situation is such that PEP 384 is self-contradicting when it comes to header files and structures. However, I guess that PEP 384 compliance is not as strict for built-in modules as it is for third party modules?

So, should bpo-2897 be resolved first before continuing with this PR?

Guessing that this PR is on hold until this is sorted out, @vstinner. Perhaps the bpo can be closed without this.