On Thu, Feb 24, 2022 at 3:27 PM Victor Stinner <vstin...@python.org> wrote:
> On Thu, Feb 24, 2022 at 11:10 PM Barry <ba...@barrys-emacs.org> wrote: > > > "Python 3.11 and newer versions use C11 without optional features. The > > > public C API should be compatible with C++." > > > https://github.com/python/peps/pull/2309/files > > > > Should is often read as meaning optional when writing specs. > > Can you say “must be compatible with C++”. > > I plan to attempt to write an actual test for that, rather than a > vague sentence in a PEP. For now, "should" is a deliberate choice: I > don't know exactly which C++ version should be targeted and if it's > really an issue or not. > Agreed. "should" is good because we're not even clear if we currently actually comply with C++ standards. i.e. https://bugs.python.org/issue40120 suggests we technically may not for C++ (it is not strictly a superset of C as we all like to pretend), though for practical purposes regardless of standards compilers tend to allow that. We're likely overspecifying in any document we create about what we require because the only definition any of us are actually capable of making for what we require is "does it compile with this compiler on this platform? If yes, then we appear to support it. can we guarantee that? only with buildbots or other CI" - We're generally not versed in specific language standards (aside from compiler folks, who is?), and compilers don't comply strictly with all the shapes of those anyways for either practical or hysterical reasons. So no matter what we claim to aspire to, reality is always murkier. A document about requirements is primarily useful to give guidance to what we expect to be aligned with and what is or isn't allowed to be used in new code. Our code itself always has the final say. -gps > For example, C++20 reserves the "module" keyword, whereas Python uses > it in its C API. Example: > > PyAPI_FUNC(int) PyModule_AddType(PyObject *module, PyTypeObject *type); > > See: > > * https://bugs.python.org/issue39355 > * https://github.com/pythoncapi/pythoncapi_compat/issues/21 > > -- > > I made a change in the datatable project to add Python 3.11 support > using the pythoncapi_compat.h header file. Problem: this *C* header > file produced new warnings in datatable extension module which with > built with a C++ compiler: > https://github.com/h2oai/datatable/pull/3231#issuecomment-1032864790 > > Examples: > > | src/core/lib/pythoncapi_compat.h:272:52: warning: zero as null > pointer constant [-Wzero-as-null-pointer-constant] > | || tstate->c_profilefunc != NULL); > | ^~~~ > | nullptr > > and > > | src/core/lib/pythoncapi_compat.h:170:12: warning: use of old-style > cast [-Wold-style-cast] > | return (PyCodeObject *)_Py_StealRef(PyFrame_GetCode(frame)); > | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I made pythoncapi_compat.h compatible with C++ (fix C++ compiler > warnings) by using nullptr and reinterpret_cast<TYPE>(EXPR) cast if > the __cplusplus macro is defined, or NULL and ((TYPE)(EXPR)) cast > otherwise. > > datatable also uses #include "Python.h". I don't know there were only > C++ compiler warnings on "pythoncapi_compat.h". Maybe because > datatable only uses static inline functions from > "pythoncapi_compat.h", but it may also emit the same warnings if > tomorrow some static inline functions of "Python.h" are used. > > For now, I prefer to put a reminder in PEP 7 that the "Python.h" C API > is consumed by C++ projects. > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/RGNBM5CSUPBQSTZND4PHEV3WUEKS36TP/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XUPAVKB7S2NCOGQY2JUMDBSTJADIOBPY/ Code of Conduct: http://python.org/psf/codeofconduct/
