On Mon, Oct 29, 2018, at 05:38, Victor Stinner wrote:
Le lun. 29 oct. 2018 à 06:32, Benjamin Peterson email@example.com a écrit :
My overall approach is to make sure that we don't leak functions by mistakes into the public API or into the stable API anymore. For example, if a function is really for the core, put it in pycore/. It will be more explicit when reviewing a change for example.
How does the current Include/internal/ directory fail at accomplishing your goal?
Hum, let me understand how I came into this issue. I tried to convert _PyObject_GC_TRACK() macro to a static inline function. The macro uses "_PyGC_generation0" which is defined earlier as: "extern PyGC_Head *_PyGC_generation0;". Problem: this symbol has been removed when Eric Snow moved it into _PyRuntime which contains "#define _PyGC_generation0 _PyRuntime.gc.generation0".
Hum, how is possible that _PyObject_GC_TRACK() of objimpl.h works as expected?
It seems like all C file using this macro explicitly uses #include "internal/pystate.h" which uses #include "internal/mem.h". Oh.
To me, it seems wrong that a function or macro defined in Include/objimpl.h requires an explicit #include "internal/pystate.h". objimpl.h should be self-sufficient.
I agree. I would say nothing in Include/*.h should be including Include/internal/*.h. We should move things into the "public" headers as required to fix this.
I started to hack Include/internals/*.h, but then I have been traped by #include which is relative: an include from Include/internals/ first looks for the included file in Include/internals/. It means that Include/internals/mem.h cannot include Include/objimpl.h if Include/internals/objimpl.h also exists.
Yeah, that's unfortunate. I suppose you could use <> includes.
Well, I would like to reorganize all these headers to make them more consistent, and converting macros to static inline functions force me to fix dependencies between header files.
How does the your /pycore/ proposal fix this?