OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Rename Include/internals/ to Include/pycore/



On Mon, Oct 29, 2018, at 05:38, Victor Stinner wrote:
> Le lun. 29 oct. 2018 ? 06:32, Benjamin Peterson <benjamin at python.org> 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?