Expose capsule type in types module

[pitrou]

Feature or enhancement

Proposal:

It would be nice if the type of capsule objects was exposed in the types module, just like other interpreter types.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-109599: Add types.CapsuleType #109600
• gh-109599: Expose CapsuleType via the _types module #131969

[pitrou]

This came up initially in #109562

[serhiy-storchaka]

What is the use case? AFAIK capsule objects are never used in the Python API. They are used in the C API, so perhaps ctypes is a better place? Although I do not know how it can be used there too.

From user's point of view the only difference of capsule type from object is its __repr__ and __doc__. You cannot create a capsule object, you cannot use its methods or attributes, there is no Python API that returns or takes a capsule object.

Not every builtin type is exposed in types module.

[pitrou]

The use case is introspection, as with other types in the types module.

Also, please take a look at the issue I mentioned above, where the context is explained in a bit more detail: #109562

[serhiy-storchaka]

How can it help in introspection? What can you do with a capsule object in Python?

The same argument can be applied to list_iterator. I am against cluttering types module.

[pitrou]

Again, the problem I'm trying to solve is explained in the #109562 issue description.
I personally think a parametric type in the typing module would be better (so that one can specificy the capsule name, such as typing.Capsule["dltensor"]), but types.CapsuleType would still be better than nothing.

You don't have to understand or care about that problem, but then please don't throw around dismissive opinions such as "I'm against cluttering X". This is unhelpful and hostile.

[serhiy-storchaka]

I'm sorry that I was categorical. This is just my personal opinion and you are free to ignore it. But I hope that you will consider other options for solving your problem. Cluttering the types module has disadvantages.

[JelleZijlstra]

I would support adding this type. None and NotImplemented also have no Python-visible API to speak of, and yet we added NoneType and NotImplementedType to the types module.

[erlend-aasland]

It looks to me this was implemented; can we close this, @pitrou?

[pitrou]

Yes, sorry. I always forget that merging a PR does not automatically close the associated issue.