Nevermind, my comment got cross-posted with #116946 (comment). So apparently, it would be safer to not change the immutability of those types for now.

Yeah, I found a few other types that don't need this. But as I said in the PR description:

For now, I've kept the assertions relatively relaxed to make it easier to review, but I'll strengthen those assertions and address any bugs in a follow-up.

This PR is pretty big already, and I would like to avoid sprinkling in behavior changes. Once your work with #116946 is done, we can strengthen the assertions in _PyObject_VisitType (e.g., requiring Py_TPFLAGS_IMMUTABLETYPE not to be set).

Most of these are cases where the object actually doesn't needs to have GC at all, they are empty objects with immutable types. Instead of adding this why not just remove GC from them? It will help in performance and reduce gc pressure.

Also in future when improving the assertions, how would you check for empty objects?

Also in future when improving the assertions, how would you check for empty objects?

Something like assert(!PyType_HasFeature(tp, Py_TPFLAGS_IMMUTABLETYPE)). We couldn't add it here because of what you stated -- a lot of these don't actually need the GC. Bénédikt is working on finding those types, but I wouldn't go as far as to say that most types here don't need it.

Most of these are cases where the object actually doesn't needs to have GC at all, they are empty objects with immutable types. Instead of adding this why not just remove GC from them? It will help in performance and reduce gc pressure.

Also in future when improving the assertions, how would you check for empty objects?

Also, I want to work on this.

Unless there is a good reason to add this private function to the public C API, I would prefer to move it to the internal C API: see my PR #139734.

If tomorrow, this function becomes popular and very useful outside CPython, I would suggest to make it public. But for now, I would prefer to keep it in the internal C API.

I kept it in public headers here to avoid adding #include "pycore_object.h" everywhere, so I have no objections to moving it to the internal headers.

I kept it in public headers here to avoid adding #include "pycore_object.h" everywhere, so I have no objections to moving it to the internal headers.

Later, it's easy to make it public: add it again to the public C API as PyObject_VisitType(). But if it stays in the public C API as a private name, users will start using it and we cannot change it later :-(