gh-141004: Document Py_ARRAY_LENGTH macro - #141601
Conversation
Sorry, something went wrong.
Added documentation for the Py_ARRAY_LENGTH macro, explaining its usage and requirements.
|
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. |
Sorry, something went wrong.
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? |
Sorry, something went wrong.
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
| 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"
Sorry, something went wrong.
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 ..."?
Sorry, something went wrong.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
"roughly equivalent to" is fine with me.
Sorry, something went wrong.
Removed redundant explanation of array size calculation.
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
ZeroIntensity
left a comment
There was a problem hiding this comment.
Happy to see a new contributor :)
Sorry, something went wrong.
|
|
||
| .. 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.
Sorry, something went wrong.
| 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".
Sorry, something went wrong.
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
Thanks, I've been hoping to contribute to python since the longest time tbh 😄 |
Sorry, something went wrong.
|
Please address my comments and then I'll merge this. |
Sorry, something went wrong.
I realize that VLAs also don't have a known size at compile-time.
ZeroIntensity
left a comment
There was a problem hiding this comment.
LGTM.
Sorry, something went wrong.
vstinner
left a comment
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
|
Thanks @Yashp002 for the PR, and @ZeroIntensity for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
Sorry, something went wrong.
(cherry picked from commit e0773ea) Co-authored-by: Yashraj <yashrajpala8@gmail.com> Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
|
GH-141895 is a backport of this pull request to the 3.14 branch. |
Sorry, something went wrong.
(cherry picked from commit e0773ea) Co-authored-by: Yashraj <yashrajpala8@gmail.com> Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
|
GH-141896 is a backport of this pull request to the 3.13 branch. |
Sorry, something went wrong.
|
Congrats on your first contribution @Yashp002 :) |
Sorry, something went wrong.
gh-141004: Document `Py_ARRAY_LENGTH` (GH-141601) (cherry picked from commit e0773ea) Co-authored-by: Yashraj <yashrajpala8@gmail.com> Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
gh-141004: Document `Py_ARRAY_LENGTH` (GH-141601) (cherry picked from commit e0773ea) Co-authored-by: Yashraj <yashrajpala8@gmail.com> Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
This PR adds documentation for the Py_ARRAY_LENGTH macro to the C API documentation, addressing issue #141004.
The documentation is placed in the "Useful macros" section of Doc/c-api/intro.rst and includes:
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/