gh-134819: Add sys.set_object_tags and sys.get_object_tags

[corona10]

• Issue: Add sys.set_object_tags() and sys.get_object_tags() APIs for debugging and experimental Use #134819

[corona10]

@vstinner@colesbury@Fidget-Spinner@ZeroIntensity
Before making more progress, including documentation stuff.
I would like to get feedback on the current implementation.

[ZeroIntensity]

This definitely isn't safe on its own. (Trust me, I've gone down quite the rabbithole in getting arbitrary object immortalization working. It's extraordinarily complex to do safely.)

[corona10]

Hmm, do you think that we should not allow setting "immortal" tag at this moment?

[ZeroIntensity]

Yeah, at least for now. sys.set_object_tags is allowed to ignore tags, right?

[corona10]

Yeah, we will ignore (and it's intended behavior)

[vstinner]

Before making more progress, including documentation stuff. I would like to get feedback on the current implementation.

As I wrote in the issue, I dislike this API and I prefer the current design: one function per object attribute, such as sys._is_immortal().

[corona10]

As I wrote in the issue, I dislike this API and I prefer the current design: one function per object attribute, such as sys._is_immortal()

The problem is that the alternative implementation also needs to provide the same functions to pass the unittests and avoid people from checking attributes based on the CPython-only function. So this API will remove unnecessary additional APIs that are only for checking the CPython implementation detail.

I also dislike that we are exposing CPython implementation detail to the pure Python function.
(C API is fine.. It's highly intertwined with CPython.)

[corona10]

So if you think that we're fine with exposing CPython implementation details through Python and C API. I can happily drop this proposal.

[colesbury]

I agree with @vstinner here and still feel the same way as in my comment on the issue. I am also not in a rush to expose these APIs at the Python level.

[ZeroIntensity]

I'm indifferent. I see arguments for both sides that both make sense.

In general, I think we do need a way to expose unstable APIs to Python the same way we do in C. It's definitely not fun to have to set up a C extension just so you can get something that is useful at a Python level (e.g., deferred reference counting). I think Donghee makes a good point that prefixing with _ isn't a sufficient way to do that. Rather than getting hung up on how object implementation details will be exposed, I think we should focus on the bigger picture. How should we expose implementation details to Python, regardless of objects in specific?

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[vstinner]

I suggest closing this change.