On Sun, 3 Feb 2019 23:22:25 +0100 Victor Stinner <vstinner at redhat.com> wrote: > Hi Antoine, > > The rules to decide what goes where have been discussed in the issues which > created Include/cpython/ and the issue moving more headers to > Include/internal/. > > In short, internal/ should not be used outside CPython codebase. In Python > 3.7, these headers were even not installed. I chose to install them because > I moved more headers into internal/ which is a backward incompatible > change. You should not use these headers outside CPython code base, but the > typical use case to use them are debug tools: debugger, tracer and > profiler. The internal/ subdir is not included in Python default search > path when you use python-config --cflags for example. It is a deliberate > choice that these headers are not easily accessible. > > There file names are prefixed by pycore_ for practical reasons: if 2 header > files have the same name in internal/ and Include/, the C preprocessor can > pick the wrong one. See the internal/ issue which gives a concrete example > (but in Python 3.7). > > cpython/ is just a practical separation to force developers to decide if a > new API is part of the stable API or not. Previously, too many APIs have > been added to the stable API by mistake (not on purpose). Hmm, I see. Thanks for the explanation. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4