My short comment: +1 My longer comment: for someone who is not trying to be caught up in "internals" I find it extremely difficult to work with the "default" approach described below - trying to mentally understand, and remember what those macros mean/do as I got "bug-hunting".
Ultimately, have a clear-cut division between "public" and "internal" make it much much easier for "the rest of us" to know our boundaries and thereby develop code that is based on the "published" aka public API and not a (guess what I found) internal trick. Isn´t that why there is a "public" API to begin with. Where, or how the separation is provided is not the key issue. But being committed to it is, and this sounds like a step towards commitment and clarity. > On 10/28/2018 6:20 PM, Victor Stinner wrote: > IMHO the current design of header files is done backward: by default, > everything is public. To exclude an API from core or stable, "#ifdef > Py_BUILD_CORE" and "#ifndef Py_LIMITED_API" are used. This design > caused issues in the past: functions, variables or something else > exposed whereas they were supposed to be "private". > > I propose a practical solution for that: Include/*.h files would only > be be public API. The "core" API would live in a new subdirectory: > Include/pycore/*.h. Moreover, files of this subdirectory would have > the prefix "pycore_". For example, Include/objimpl.h would have a > twin: Include/pycore/pycore_objimpl.h which extend the public API with > "core" APIs.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
