gh-129675: Update documentation for tp_basicsize & tp_itemsize#129850
Merged
Conversation
- Add alignment requirement - Mention that ob_size is unreliable if you don't control it - Add some links for context - basicsize should include the base type in generaly not just PyObject This adds a “by-the-way” link to `PyObject_New`, which shouldn't be used for GC types. In order to be comfortable linking to it, I also add a link to `PyObject_GC_New` from its docs. And the same for `*Var` variants, while I'm here.
encukou
commented
Feb 17, 2025
Comment on lines
-603
to
-604
| exceptions: for example, ints use a negative :c:member:`~PyVarObject.ob_size` to indicate a | ||
| negative number, and N is ``abs(ob_size)`` there. Also, the presence of an |
Member
Author
There was a problem hiding this comment.
@markshannon FWIW, here's another piece of documentation that says abs(ob_size) gives you the size of a PyLongObject.
Member
ZeroIntensity
left a comment
There was a problem hiding this comment.
Mostly LGTM. Feel free to ignore any of my comments, these are pretty much just what I thought to myself as I read through it.
encukou
commented
Mar 10, 2025
Member
Author
encukou
left a comment
There was a problem hiding this comment.
Thanks for the review!
Things can always be improved, but it looks like this iteration is good to go.
|
Thanks @encukou for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12. |
|
Thanks @encukou for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13. |
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this pull request
Mar 11, 2025
…ythonGH-129850) * Update documentation for tp_basicsize & tp_itemsize - Add alignment requirement - Mention that ob_size is unreliable if you don't control it - Add some links for context - basicsize should include the base type in generaly not just PyObject This adds a “by-the-way” link to `PyObject_New`, which shouldn't be used for GC types. In order to be comfortable linking to it, I also add a link to `PyObject_GC_New` from its docs. And the same for `*Var` variants, while I'm here. * Strongly suggest Py_SIZE & Py_SET_SIZE (cherry picked from commit ad0f618) Co-authored-by: Petr Viktorin <encukou@gmail.com>
|
GH-131078 is a backport of this pull request to the 3.12 branch. |
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this pull request
Mar 11, 2025
…ythonGH-129850) * Update documentation for tp_basicsize & tp_itemsize - Add alignment requirement - Mention that ob_size is unreliable if you don't control it - Add some links for context - basicsize should include the base type in generaly not just PyObject This adds a “by-the-way” link to `PyObject_New`, which shouldn't be used for GC types. In order to be comfortable linking to it, I also add a link to `PyObject_GC_New` from its docs. And the same for `*Var` variants, while I'm here. * Strongly suggest Py_SIZE & Py_SET_SIZE (cherry picked from commit ad0f618) Co-authored-by: Petr Viktorin <encukou@gmail.com>
|
GH-131079 is a backport of this pull request to the 3.13 branch. |
encukou
added a commit
to rhansen/cpython
that referenced
this pull request
Mar 11, 2025
encukou
added a commit
that referenced
this pull request
Mar 17, 2025
…GH-129850) (GH-131078) - Add alignment requirement - Mention that ob_size is unreliable if you don't control it - Add some links for context - basicsize should include the base type in generaly not just PyObject - suggest Py_SIZE & Py_SET_SIZE This adds a “by-the-way” link to `PyObject_New`, which shouldn't be used for GC types. In order to be comfortable linking to it, I also add a link to `PyObject_GC_New` from its docs. And the same for `*Var` variants, while I'm here. (cherry picked from commit ad0f618) Co-authored-by: Petr Viktorin <encukou@gmail.com>
encukou
added a commit
that referenced
this pull request
Mar 17, 2025
…GH-129850) (GH-131079) - Add alignment requirement - Mention that ob_size is unreliable if you don't control it - Add some links for context - basicsize should include the base type in generaly not just PyObject - suggest Py_SIZE & Py_SET_SIZE This adds a “by-the-way” link to `PyObject_New`, which shouldn't be used for GC types. In order to be comfortable linking to it, I also add a link to `PyObject_GC_New` from its docs. And the same for `*Var` variants, while I'm here. (cherry picked from commit ad0f618) Co-authored-by: Petr Viktorin <encukou@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds a “by-the-way” link to
PyObject_New, which shouldn't be used for GC types. In order to be comfortable linking to it, I also add a link toPyObject_GC_Newfrom its docs. And the same for*Varvariants, while I'm here.📚 Documentation preview 📚: https://cpython-previews--129850.org.readthedocs.build/