gh-141004: Document Py_ARRAY_LENGTH macro #141601
Conversation
Added documentation for the Py_ARRAY_LENGTH macro, explaining its usage and requirements.
bedevere-app
bot
added
awaiting review
docs
StanFromIreland
changed the title
|
Our CI does not like it when the branch the PR is opened from is called "main" IIRC and that is why some extra tests are running. |
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
|
Also, is it a generally good practice to break off a branch from the main while working on it myself then? |
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Doc/c-api/intro.rst
Outdated
| compilation error, otherwise, using this macro with a pointer will | ||
| produce incorrect results. | ||
|
|
||
| This is generally equivalent to:: |
There was a problem hiding this comment.
I don't like the use of "generally" equivalent because it may indicate that it's equivalent to something else. So I would remove the "This is generally equivalent to:: + code"
There was a problem hiding this comment.
I disagree, it's helpful to have something rather than nothing, even if it's not 100% true. This is a good example of a lie-to-children.
If you're against "generally", how about saying "this is semantically equivalent to ..."?
There was a problem hiding this comment.
"generally" is inaccurate; if you want to lie a bit, you should say "roughly equivalent to" (which is what we do in academia or in itertools btw). "Generally" means that this would always be the case (at least to me when used like that), but the macro expansion is different.
- If you want to use "generally" as a synonym of "usually", "roughly" is better.
- "semantically equivalent" is too verbose IMO.
There was a problem hiding this comment.
"roughly equivalent to" is fine with me.
picnixz
changed the title
Removed redundant explanation of array size calculation.
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
ZeroIntensity
left a comment
ZeroIntensity
left a comment
There was a problem hiding this comment.
Happy to see a new contributor :)
|
|
||
| .. c:macro:: Py_ARRAY_LENGTH(array) | ||
| Compute the length (number of elements) of a statically allocated C array at |
There was a problem hiding this comment.
I think it's generally well known that the length is the number of elements.
| The *array* argument must be a C array with a size known at compile time, | ||
| not a pointer. On supported compilers, passing a pointer will result in a |
There was a problem hiding this comment.
All arrays can be represented as a pointer, statically allocated or not. Let's instead say something like "heap-allocated array" instead of "pointer".
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
Thanks, I've been hoping to contribute to python since the longest time tbh 😄 |
|
Please address my comments and then I'll merge this. |
4 participants
This PR adds documentation for the
Py_ARRAY_LENGTHmacro to the C API documentation, addressing issue #141004.The documentation is placed in the "Useful macros" section of
Doc/c-api/intro.rstand includes:sizeof(array) / sizeof((array)[0])This macro has existed since Python 2.7 but was previously undocumented in the official C API documentation.
📚 Documentation preview 📚: https://cpython-previews--141601.org.readthedocs.build/