GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing github.com — gh-107298: Document PyAPI_DATA() macro by vstinner · Pull Request #109129 · python/cpython Conversation
|
|
I saw these Sphinx warnings on a PR which doesn't touch |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Yep, all Sphinx warnings are logging during docs builds, regardless of whether you touch the actual file. For example, this PR has the remaining warnings for that file: |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| macro should only be used in Python C API. Example:: | ||
|
|
||
| PyAPI_DATA(const unsigned long) Py_Version; | ||
|
|
||
| .. c:macro:: PyAPI_FUNC(type) | ||
|
|
||
| Declare a function with a return type *type* which should be exported by | ||
| Python. The macro should only be used in Python C API. Example:: | ||
|
|
||
| PyAPI_FUNC(PyObject *) PyLong_FromLong(long); | ||
|
|
||
| .. c:macro:: PyMODINIT_FUNC | ||
|
|
||
| Declare an extension module ``PyInit`` initialization function. The return | ||
| type is :c:expr:`PyObject*`. The macro should only be used in Python C API. |
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Little suggestion adding 3 x "the":
| macro should only be used in Python C API. Example:: | |
| PyAPI_DATA(const unsigned long) Py_Version; | |
| .. c:macro:: PyAPI_FUNC(type) | |
| Declare a function with a return type *type* which should be exported by | |
| Python. The macro should only be used in Python C API. Example:: | |
| PyAPI_FUNC(PyObject *) PyLong_FromLong(long); | |
| .. c:macro:: PyMODINIT_FUNC | |
| Declare an extension module ``PyInit`` initialization function. The return | |
| type is :c:expr:`PyObject*`. The macro should only be used in Python C API. | |
| macro should only be used in the Python C API. Example:: | |
| PyAPI_DATA(const unsigned long) Py_Version; | |
| .. c:macro:: PyAPI_FUNC(type) | |
| Declare a function with a return type *type* which should be exported by | |
| Python. The macro should only be used in the Python C API. Example:: | |
| PyAPI_FUNC(PyObject *) PyLong_FromLong(long); | |
| .. c:macro:: PyMODINIT_FUNC | |
| Declare an extension module ``PyInit`` initialization function. The return | |
| type is :c:expr:`PyObject*`. The macro should only be used in the Python C API. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Are PyAPI_FUNC() and PyAPI_DATA() purposed to be used in a third-party code at all?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
I wrote "The macro should only be used in Python C API." They should not be used outside Python code base. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Then should we explicitly document them as "internal"? Or not document at all and silence the warnings? Which leads to a third question: why are other docs referring to internal things? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There is no clear separation between public and internal APIs in the documentation. But the internal API is almost not documented at all. So far, I only saw 2 functions: _PyBytes_Resize() and _PyTuple_Resize(). Last years, I removed mentions of many private C API functions like _Py_NewReference() or PyImport_Cleanup(). I even removed PyImport_Cleanup() from the public C API (I made it internal) :-) I was surprised to see: https://docs.python.org/dev/library/test.html
One day, it was proposed to have a separated documentation for the internal APIs, but nobody proposed anything concrete. Sometimes I wish I could document these internal APIs, but I cannot, since their documentation has no home! |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
I would be fine with that as well. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Ok, I created the opposite change: PR #109236 removes links to these 3 macros. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@serhiy-storchaka Which do you prefer? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
(I prefer to not document them, PR #109236.) |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Sounds good to me. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I close this PR, let's continue the discussion in PR #109236. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.