object.__sizeof__(1) have different output between 3.9.10 and 3.12.2

[oldoldman]

Bug report

Bug description:

on a Windows x64 machine

>>> #python 3.9.10
>>> object.__sizeof__(1)
28
>>>

>>> #python 3.12.2
>>> object.__sizeof__(1)
56
>>>

CPython versions tested on:

3.9, 3.12

Operating systems tested on:

Windows

Linked PRs

• GH-117195: Avoid assertion error in object.__sizeof__ #117220
• [3.13] GH-117195: Avoid assertion error in object.__sizeof__ (GH-117220) #119456

[terryjreedy]

In 3.11, size of -1000, -1, 0, 1. 1000 are 20, 20, 24, 28, 28. In 3.13, 64, 64, 28, 56 , 56. I am not sure if really a 'bug' rather than intentional, but the only mention of 'size of' in 3.12 What's New is that str object size decreased and no mention that size of ints doubled. I seem's like a regression in memory use. The changelog has several mentions of sizes decreasing and only mentions a stack size increase.

[pochmann3]

object.__sizeof__(1) gives me 56, but int.__sizeof__(1) and 1 .__sizeof__() and sys.getsizeof(1) all give me 28. And id(1) - id(0) and id(2) - id(1)) both give me 32. So it's certainly only object.__sizeof__ misreporting the size. (In Python 3.12.0.)

[Eclips4]

It's ends up with an assertion error on debug build for me (current main branch):

./python
Python 3.13.0a5+ (heads/main:eebea7e515, Mar 24 2024, 21:43:31) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> object.__sizeof__(1)
python: ./Include/object.h:344: Py_SIZE: Assertion `ob->ob_type != &PyLong_Type' failed.
Aborted

[vitaldmit]

./python
Python 3.13.0a5+ (heads/main:9967b568ed, Mar 23 2024, 16:10:16) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> object.__sizeof__(1)
56

[Eclips4]

./python
Python 3.13.0a5+ (heads/main:9967b568ed, Mar 23 2024, 16:10:16) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> object.__sizeof__(1)
56

Is this a debug build? For the debug build, you should use ./configure --with-pydebug on Linux or pcbuild/build.bat -c Debug on Windows

[ronaldoussoren]

Note that the result of object.__sizeof__(1) being an unexpected value is not necessarily a bug, the __sizeof__ method is overridden in int and gives the expected value there. Also as a user the interface to get the size of an object is sys.getsizeof(1).

The crash in debug mode is likely because PyLongObject is not a PyVarObject in 3.12 even though the type has ob_itemsize set to a nonzero value. In 3.9 the type is a PyVarObject, but doesn't follow the protocol entirely because the sign of the int value is stored in ob_itemsize.

I'm not familiar enough with the code in longobject.c and its evolution to know what's the best fix for 3.12. Long term it is probably better to unset ob_itemsize, but who knows what will break when that change is made in 3.12.

[Eclips4]

Perhaps @markshannon is the right person for this discussion.

[markshannon]

The result of object.__sizeof__(1) is not meaningful, but it shouldn't crash.