On 10. 12. 21 11:55, Christian Heimes wrote:
On 10/12/2021 03.08, Jim J. Jewett wrote:
Christian Heimes wrote:
On 09/12/2021 19.26, Petr Viktorin wrote:
If the code is the authoritative source of truth, we need a proper
parser to extract the information. ... unfortunately I don't trust it
enough to let it define the API. Bugs in the parser could result in
the API definition silently changing.
There are other options than writing a new parser. GCC and Clang are
flexible. For example GCC can be extended with plugins and custom
attributes.
But they have the same problem ... it can be difficult to know if
there is a subtle bug in someone's understanding of how the plugin
interacts with, for example, nested ifndef.
The failure mode for an explicitly manually maintained text file is
that something doesn't get added when it should, and the more
conservative API consumers wait an extra release before using it.
Macros and ifndefs are not a problem.
They are: we want to find PyErr_SetExcFromWindowsErr on all systems, and
include it in the docs.
A GCC plugin for user-defined
attributes hooks into the build process at a late stage. By the time the
plugin hook is invoked, the precompiler has resolved all macros and
ifdefs, and the C code has been parsed. The plugin operates on the same
intermediate code as the compiler.
The approach would allow us to make the headers the authoritative source
for most API and ABI symbols. I don't think that we can use it for
macros. We can even include additional metadata in the custom attribute,
e.g. version added
PyAPI_ABI_FUNC("3.2", PyObject *) PyLong_FromLong(long);
This looks a bit awkward already, and if/when we start including e.g.
"version removed" for PyAPI_ABI_ONLY, it'll get worse.
We can convert Misc/stable_abi.txt into an auto-generated file. The file
should still stay in git, so we can use it to verify the stable ABI in CI.
We can, but genuinely I think it works better as a source of truth than
a generated artifact. Changes to it should be deliberate.
I get that not everyone will agree with that. But it's also *much*
easier to maintain the current "best-effort" checks (which can punt on a
few edge cases) than add an all-encompassing, tested parser-based generator.
Not everything needs to be automated :)
Eric said:
The tooling is a secondary concern to my point. Mostly, I wish the
declarations in the header files had the extra classifications, rather than
having to remember to refer to a separate text file.
This part sounds like a good idea.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/HSIUJSE6QW2U4QEEHFOZSQIDD7Q3DT7G/
Code of Conduct: http://python.org/psf/codeofconduct/
