<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>My short comment: +1</p>
<p>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".</p>
<p>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.</p>
<p>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.<br>
</p>
<br>
<div class="moz-cite-prefix">On 10/28/2018 6:20 PM, Victor Stinner
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CA+3bQGE7UriagGc_FYuM7ge5oGX+6+_w2c3HY1WDj8JY=6FuzQ@mail.gmail.com">
<pre wrap="">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.</pre>
</blockquote>
<br>
</div></body></html>