Repository navigation
object.__sizeof__(1) have different output between 3.9.10 and 3.12.2 #117195
Description
Activity
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.
object.__sizeof__(1)gives me 56, butint.__sizeof__(1)and1 .__sizeof__()andsys.getsizeof(1)all give me 28. Andid(1) - id(0)andid(2) - id(1))both give me 32. So it's certainly onlyobject.__sizeof__misreporting the size. (In Python 3.12.0.)Reacted by Kirill PodoprigoraIt'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
Reacted by Stefan./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
./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-pydebugon Linux orpcbuild/build.bat -c Debugon WindowsNote that the result of
object.__sizeof__(1)being an unexpected value is not necessarily a bug, the__sizeof__method is overridden inintand gives the expected value there. Also as a user the interface to get the size of an object issys.getsizeof(1).The crash in debug mode is likely because PyLongObject is not a PyVarObject in 3.12 even though the type has
ob_itemsizeset to a nonzero value. In 3.9 the type is a PyVarObject, but doesn't follow the protocol entirely because the sign of theintvalue is stored inob_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.Reacted by Kirill Podoprigora and Виталий ДмитриевPerhaps @markshannon is the right person for this discussion.
The result of
object.__sizeof__(1)is not meaningful, but it shouldn't crash.
Bug report
Bug description:
on a Windows x64 machine
CPython versions tested on:
3.9, 3.12
Operating systems tested on:
Windows
Linked PRs
object.__sizeof__#117220object.__sizeof__(GH-117220) #119456object.__sizeof__(GH-117220) #127605