Skip to content

Conversation

@kumaraditya303
Copy link
Contributor

@kumaraditya303 kumaraditya303 commented Feb 6, 2026

Copy link
Member

@ZeroIntensity ZeroIntensity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we also need to document the guarantees regarding which objects may be made immortal. For example, the following results in an assertion failure:

from ctypes import pythonapi, py_object, c_int

set_immortal = pythonapi.PyUnstable_SetImmortal
set_immortal.argtypes = (py_object,)
set_immortal.restype = c_int

print(set_immortal("Hello world"))

Copy link
Member

@ZeroIntensity ZeroIntensity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good.

Bikeshedding: Should this be named PyUnstable_Object_SetImmortal? The Py[Unstable]_ prefix is generally reserved for runtime operations (though it seems PyUnstable_TryIncRef didn't follow that rule).

creates it, such as in the object's :c:member:`~PyTypeObject.tp_new` slot.
Returns 1 if the object was made immortal and returns 0 if it was not.
This function cannot fail.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you, but it's likely worth mentioning that this is useful for avoiding reference count contention.

@kumaraditya303
Copy link
Contributor Author

Should this be named PyUnstable_Object_SetImmortal?

I'd like to keep it aligned with PyObject_IsImmortal and avoid introducing the Object in between.

@kumaraditya303 kumaraditya303 marked this pull request as ready for review February 10, 2026 14:11
Comment on lines +811 to +812
made mortal once again. Immortal objects do not participate in reference counting
and will never be garbage collected.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, we also need to note that op will be GC-untracked if it's tracked.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it the same as never garbage collected?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that's immediately clear. Something can be "never garbage collected" while still being GC-tracked without being immortal (such as with a reference leak). It'd be nice for users to know that they don't need to call PyObject_GC_UnTrack themselves.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants