This storage is an attempt to make the struct of this PEP. Here is the new struct:
Add “legacy.h”. Now it contains:
#ifndef Py_LEGACY_H
#define Py_LEGACY_H
#ifdef Py_OMIT_LEGACY_API
#include "pyconfig_undef.h"
// Undefine legacy APIs here as needed
// Which macros to undefine is depended on CPython core developers' decision.
#endif /* Py_OMIT_LEGACY_API */
#endif /* !Py_LEGACY_H */
Add the tool “python_undef” to generate “pyconfig_undef.h”: This file is to undefine the non-standard macros (such as “HAVE_*”, “SIZE_*” and so on) in “pyconfig.h”. Considering that the “pyconfig.h” is dynamic, this file is too. This file will be ignore by “.gitignore” but will be installed by “install”. It will run automatically after the python being built successfully.
Now “Python.h” will include “legacy.h” at the tail. And when defined the macro “Py_OMIT_LEGACY_API” the code by PEP743 will run. What will be contained in this macro is depended by cpython core developmenter.
The macro “Py_DONOTUNDEF_XXX” will save XXX which is defined in “pyconfig.h”. From 3.15(or 3.16) to 3.17 it is normal. From 3.18 to 3.19 it will warning. After 3.20 it won’t work.
The known bug:
On windows, the “pyconfig.h” redefines some macros that the compiler had defined, and the tool will handle them as a normal non-standard macro and undefine. I had to write a whitelist to exclude (maybe we have another way to change it).
On unix, the python will be compiled twice (though finally successful). Maybe the reason is that the tool generate the file to the directly “Include”.
No, you completely misunderstand PEP 743: It is not intended as a bandage that just undefs a few macros that do not have the usual prefix. Moreover, what about function declarations with your approach? You cannot undef them!
Instead, PEP 743 is about a cleanup of the whole API, which includes some new functions and some new names for existing things. Macros that are not part of the API will not be undefined! They will be not defined at all if Py_OMIT_LEGACY_API is defined. The same with functions: the declaration will be hidden from the compiler if Py_OMIT_LEGACY_API is defined.
To the moderators: Could this thread be moved somewhere else. The PEP category is only for the discussion of PEPs.
A lot of non-mods can move threats too - there’s a pencil icon at the top of the thread where you can make edits to the subject line and category. Please don’t abuse this (eg don’t put words in people’s mouths), but it’s there so that you can, in fact, move threads to more suitable locations.
The reason to do with “pyconfig.h” is that in finally c-api, the macros from it is not fixed. For the other api (such as function) which codes will be changed is controllable.
As you see, just PEP743 itself listed many functions. Some developments listed more. It needs many PR to do it.
The “pyconfig.h” is special so it has another way, the other files’ changes will finally fill it:
// For macro
// Original
// #define MACRO
// Now
#define Py_MACRO
#ifndef Py_OMIT_LEGACY_API
#define MACRO
#endif
// For function
// Original
// PyObject* function();
// now
PyObject* Py_function();
#ifndef Py_OMIT_LEGACY_API
PyObject* function() {
// A way to warning. Python has implement it
return Py_function();
}
#endif
If follow it, the defination of some macros starts with “Py” or “_Py” will also be changed. So it is not a problem (I cannot ensure that these code where the non-standard macros decide how the standard macros will be defined won’t appear on Unix system), so this ideal plan is not suitable for “pyconfig.h”.
My idea about configure macros was to convince configure to generate them with prefixed names (e.g. _Py_HAVE_OPENAT), with legacy.h then defining the backwards-compatible name (HAVE_OPENAT).
The point of omitting #defines is to not touch names that don’t belong to us. Users should be allowed to define them themselves (before including <Python.h>). #undef doesn’t work here.
I am not sure whether it is possible to change it by this way. The omitting of #define may change the way to compile project with python api (not only the macros in “pyconfig.h”), this is what PEP743 don’t want.
How about one PR with millions of lines changing? This change may cause many other PRs conflicted.
Anyway, there is a more simple way to do it, and there is no needed to deny a way without practico. Unless it can be proved that the simple way can cause more crash, I will still push it.