gh-129675: Update documentation for tp_basicsize & tp_itemsize #129850
+83
−30
Conversation
This file contains 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
- 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 |
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.
encukou
commented
Mar 10, 2025
|
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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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/