gh-100637: Fix int and bool __sizeof__ calculation to include the 1 element ob_digit array for 0 and False

[ionite34]

Fixes behavior where int and bool __sizeof__ under-reports true size by 4 bytes as it did not take into account the size 1 ob_digit array for 0 and False.

Changes

• 88e249b Use Py_MAX to use the maximum of 1 or the absolute ob_size size.

offsetof(PyLongObject, ob_digit) + Py_MAX(Py_ABS(Py_SIZE(self)), 1)*sizeof(digit)

Testing

• 391ec87 Update sys.getsizeof unit test for int 0 to use the same size as the cases for -1 and 1
• 88e249b Add a sys.getsizeof unit test for False matching the previous test case for True

• Issue: __sizeof__ incorrectly ignores the size 1 array in PyVarObjects (bool, int, tuple) when ob_size is 0 #100637

[bedevere-bot]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[ghost]

All commit authors signed the Contributor License Agreement.

[mdickinson]

This looks good to me, and works as advertised in manual testing - thank you!

I've made one nitpick level suggestion for a stylistic change.

(Actually, thinking about style, I'm not sure why the body of this function doesn't simply consist of a single return - the res temporary seems unnecessary.)

[mdickinson]

LGTM!

I'll leave this open for a bit in case anyone else has comments (especially because it's New Year's Day and some potential commenters may be AFK), but I think this is ready to merge.

[ionite34]

(Actually, thinking about style, I'm not sure why the body of this function doesn't simply consist of a single return - the res temporary seems unnecessary.)

Thanks for the review and line split suggestion! I'm not really sure about the res over plain return either. Maybe there was a diff minimizing rationale for that original res that I'm not aware of. Currently seems fine though.

[ionite34]

Would this be something that needs backport to 3.10/3.11? Not sure what the policy is for that.

[miss-islington]

Thanks @ionite34 for the PR, and @mdickinson for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

[bedevere-bot]

GH-100717 is a backport of this pull request to the 3.11 branch.

[mdickinson]

Would this be something that needs backport to 3.10/3.11? Not sure what the policy is for that.

It's a judgement call, I think: it's arguably a bugfix, but an almost entirely inconsequential one - I can't imagine much real world code that would benefit, even though it's nice to have the fix going forward.

I'll backport to 3.11: Python 3.11 was the version that deliberately started always allocating at least one digit (the relevant commit was 15d50d7). That isn't true in Python 3.10.

(3.10 code:

cpython/Objects/longobject.c

Lines 138 to 139 in a639493

	result = PyObject_Malloc(offsetof(PyLongObject, ob_digit) +
	size*sizeof(digit));

)
(3.11 code:

cpython/Objects/longobject.c

Lines 155 to 162 in b99ac1d

	Py_ssize_t ndigits = size ? size : 1;
	/* Number of bytes needed is: offsetof(PyLongObject, ob_digit) +
	sizeof(digit)*size. Previous incarnations of this code used
	sizeof(PyVarObject) instead of the offsetof, but this risks being
	incorrect in the presence of padding between the PyVarObject header
	and the digits. */
	result = PyObject_Malloc(offsetof(PyLongObject, ob_digit) +
	ndigits*sizeof(digit));

)