Skip to content

Expose capsule type in types module #109599

Description

@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

Activity

  1. pitrou commented on Sep 20, 2023

    @pitrou
    MemberAuthor

    This came up initially in #109562

  2. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Sep 20, 2023
  3. self-assigned this
    on Sep 20, 2023
  4. serhiy-storchaka commented on Sep 20, 2023

    @serhiy-storchaka
    Member

    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.

  5. pitrou commented on Sep 20, 2023

    @pitrou
    MemberAuthor

    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

  6. serhiy-storchaka commented on Sep 20, 2023

    @serhiy-storchaka
    Member

    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.

  7. pitrou commented on Sep 20, 2023

    @pitrou
    MemberAuthor

    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.

  8. serhiy-storchaka commented on Sep 20, 2023

    @serhiy-storchaka
    Member

    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.

  9. JelleZijlstra commented on Sep 20, 2023

    @JelleZijlstra
    Member

    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.

  10. added a commit that references this issue on Sep 25, 2023
  11. added a commit that references this issue on Sep 28, 2023
  12. erlend-aasland commented on Oct 5, 2023

    @erlend-aasland
    Contributor

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

  13. pitrou commented on Oct 5, 2023

    @pitrou
    MemberAuthor

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

  14. added a commit that references this issue on Sep 2, 2024
  15. added a commit that references this issue on Apr 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

stdlibStandard Library Python modules in the Lib/ directorytype-featureA feature request or enhancement

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions