The swig package failed a test during the OCaml 5.0.0 rebuild. On an x86_64 Fedora 38 machine, with python 3.11: $ python3 Python 3.11.4 (main, Jun 7 2023, 00:00:00) [GCC 13.1.1 20230511 (Red Hat 13.1.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> x = "hello" >>> sys.getrefcount(x) 2 >>> y = x >>> sys.getrefcount(x) 3 On an x86_64 Rawhide machine, with python 3.12: $ python3 Python 3.12.0b3 (main, Jun 21 2023, 00:00:00) [GCC 13.1.1 20230614 (Red Hat 13.1.1-4)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> x = "hello" >>> sys.getrefcount(x) 4294967295 >>> y = x >>> sys.getrefcount(x) 4294967295 So (unsigned int)-1 was returned in both cases. Swig has a test that expects the second sys.getrefcount invocation to return a number 1 higher than the previous invocation. Reproducible: Always Steps to Reproduce: 1. Run the python code shown above 2. 3. Actual Results: With python 3.12, sys.getrefcount appears to return a constant. Expected Results: sys.getrefcount should behave like it did in python 3.11.
Reproducible also with 3.12.0~b4-1.fc39.
Reproducible also with /usr/bin/python3.12d
Related to PEP 683? https://peps.python.org/pep-0683/
I think it's expected behavior with "immortal" objects such as str instances, based on my reading of the PEP?
Indeed that seems to be the case. >>> x = 1 >>> sys.getrefcount(x) 4294967295 >>> x = 100000000000000 >>> sys.getrefcount(x) 2
Then it is the swig test that is wrong. I'll report this to swig upstream. Thank you, everyone!