Relax `PyUnstable_SetImmortal` to objects allocated in that thread?

[seberg]

Feature or enhancement

Proposal:

Currently PyUnstable_SetImmortal requires a uniquely referenced object. I think the docs could be a bit clearer about this but that isn't the tricky part.

The tricky part is that I think it doesn't seem uncommon to create objects which are not uniquely referenced. I have two overlapping places in NumPy where I was hope to use this while making types that were previously static to heaptypes:

1. If you have non-trivial setup code that might fail you want to immortalize at the very end. In my case I wanted to add the object to a dict (as a last step). (Sure, if I am going to immortalize it, then I can re-order adding it to the dict with a lock or so.)
2. I am using PyType_FromMetaType() and the returned object already has 3 references when created fresh.

Basically, I get the "err on the safe side" part, but from poking it a bit and looking at #113956 it seems that the real limitation seems to be that the current thread owns the object.

Ensuring the object is created on the current thread is trivial no matter how complicated object creation itself is.

CC @ngoldbaum

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

[ngoldbaum]

cc @kumaraditya303 @colesbury as well

[sergey-miryanov]

cc @ZeroIntensity as well too

[ZeroIntensity]

It is extremely unsafe to immortalize an object that isn't uniquely referenced and immutable (which heap types are not). I don't think this is something that should be in the public API -- if you really want to do it, use the private API.

[ngoldbaum]

Perhaps off-base suggestion: maybe what you really want is to enable deferred reference counting? Or are you worried about something besides scaling on the free-threaded build?

[seberg]

Sure, I guess PyUnstable_Object_EnableDeferredRefcount is probably enough then. In the end I just care to about being able to say: "nah, there is no reason to expect a perf regression" in case someone asks (because someone always do no matter if all agree that heap-types are nice to use).

These are types may be incref'd/decref'd a fair bit and at least and they are effectively immortal (and at least for own ones also immutable, since the corresponding flag is set). So immutability just seemed obvious.

[ZeroIntensity]

I think type objects use deferred reference counting by default? Maybe that's only for pure-Python types.