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

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().

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.)

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

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.

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?