@brandtbucher Not sure worth to do it at compile.c as much as an interpreter but it looks possible.

I'm a bit concerned that a change like this would make it hard to reverse the decision to make these objects immortal in the future (it is no longer clear where we need a new reference and where we don't).

Should we have Py_New_None/Py_New_Elipsis/etc macros instead, so that the code is clear about this?

Should we have Py_New_None/Py_New_Elipsis/etc macros instead, so that the code is clear about this?

I think that it will be the proper way and easy to track.

Should we have Py_New_None/Py_New_Elipsis/etc macros instead, so that the code is clear about this?

I'm not sure that will be workable. Since there is no refcount change, there will be no way to enforce that these macros are used correctly, so we're likely to regress very quickly on correct use of those macros.

@vstinner What do you think about this agenda?

Should we have Py_New_None/Py_New_Elipsis/etc macros instead, so that the code is clear about this?

I'm not sure that will be workable. Since there is no refcount change, there will be no way to enforce that these macros are used correctly, so we're likely to regress very quickly on correct use of those macros.

True. We would need a test mode where they are not immortal and the macros actually change the refcount.

True. We would need a test mode where they are not immortal and the macros actually change the refcount.

I am not sure that I understand your intention correctly, so do we need to introduce the following configuration things?
./configure --emulate-ref-count
So if such a configuration is enabled, Py_New_None will execute ref counting API?

Yes, we'd need something like that. We'd have to run at least one buildbot under that configuration mode too. I'm honestly not sure it would be worth introducing that much complexity.

One of my concerns about adding such a configuration which determining the C API or macro behavior, as @JelleZijlstra commented it should always be run under at least from the build bot with the configuration enabled. Without the integration from the CI level, such configuration is easily broken and can not guarantee to be built successfully at any time.

This is one of my lessons from the --with-experimental-isolated-subinterpreters flag:
#90988

My suggestion:
How about adding test cases(whitelist) for immortal objects from the C API side rather than adding something like emulation mode.
If we add the test code that can occur weird refcount, under the immortal object condition, the test will be passed, but if we disable the immortal object condition from a specific object, the test will be failed, and we can easily track what should be fixed.

We need a decision on whether we want to put some effort into making the move immortality reversible, or not. The technicalities are not very difficult once that decision is made. I'm not sure who should make the call, but it's not me.

@vstinner What do you think about this agenda?

The SC approved https://peps.python.org/pep-0683/ Why would be move backward and remove immortal objects?

I'm not used to immortal objects, so right now I'm surprised that some objects require Py_NewRef() whereas others don't. It makes the code less regular and so harder to review for me. But I prefer to stay outside this topic and let others review it :-)

It looks like #105195 will be merged soon.
Only applying this PR for Python 3.13 will not be harmful if the documentation exists.

I merge this PR, please let me know if the PR occurs any problem.