[Python-Dev] Rename Include/internals/ to Include/pycore/ (original) (raw)
Victor Stinner vstinner at redhat.com
Mon Oct 29 08:38:41 EDT 2018
- Previous message (by thread): [Python-Dev] Rename Include/internals/ to Include/pycore/
- Next message (by thread): [Python-Dev] Rename Include/internals/ to Include/pycore/
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 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.
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.
> PyBUILDCORE is not only used to select which functions you get. > PyBUILDCORE is also commonly used to get a macro instead of a > function call, for best performances.
I think the macro and function versions should just have different names then.
I don't want to break the backward compatibility. I would like to make small steps towards a better API. Concrete example with pystate.h:
/* Variable and macro for in-line access to current thread state */
/* Assuming the current thread holds the GIL, this is the PyThreadState for the current thread. */ #ifdef Py_BUILD_CORE
define _PyThreadState_Current _PyRuntime.gilstate.tstate_current
define PyThreadState_GET() \
((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
#else
define PyThreadState_GET() PyThreadState_Get()
#endif
We cannot remove PyThreadState_GET() from the Python C API. Removing any function is likely going to break multiple C extensions.
I don't want to change too many things at once.
My first intent is to convert _PyObject_GC_TRACK() into a static function, not to break the Python C API :-)
Victor
- Previous message (by thread): [Python-Dev] Rename Include/internals/ to Include/pycore/
- Next message (by thread): [Python-Dev] Rename Include/internals/ to Include/pycore/
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]