bpo-41861: Clean up sqlite3 header files wrt. PEP 384

[erlend-aasland]

Ref. https://www.python.org/dev/peps/pep-0384/#header-files-and-preprocessor-definitions
Also ref. bpo-2897 (PyMemberDef not part of the stable API)

https://bugs.python.org/issue41861

[erlend-aasland]

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

[erlend-aasland]

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

[erlend-aasland]

Seems like the Travis CI is stuck…

[vstinner]

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.

[erlend-aasland]

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?

[vstinner]

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

[erlend-aasland]

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?

[erlend-aasland]

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?

[erlend-aasland]

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