Skip to content

Conversation

@davidhewitt
Copy link
Member

Alternative to #5352

The idea is that PyTypeInfo::NAME is a constant value which we've historically populated incorrectly for native types anyway. Also Python is a dynamic language, let's just encourage users to get that state at runtime.

PyTypeInfo::MODULE is even worse, it is really only useful for the #[pyclass] machinery and is not populated consistently (or at all in many cases).

This PR deprecates those two constants, and:

  • Adds PyClass::NAME constant for the name which is given to the #[pyclass] by the machinery. I think it's fine for this to be public as it seems obvious how it should work.
  • Moves module information to PyClassImpl, as I think that might change in the future anyway.

Copy link
Contributor

@Tpt Tpt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Having MODULE as a private implementation things make a lot of sense. It's a footgun in its current state.

@davidhewitt davidhewitt added this pull request to the merge queue Nov 4, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Nov 4, 2025
@davidhewitt davidhewitt added this pull request to the merge queue Nov 4, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Nov 4, 2025
@davidhewitt davidhewitt enabled auto-merge November 8, 2025 18:31
@davidhewitt davidhewitt added this pull request to the merge queue Nov 8, 2025
Merged via the queue into PyO3:main with commit ebf95bd Nov 8, 2025
43 checks passed
@davidhewitt davidhewitt deleted the pyclass-name-module branch November 8, 2025 21:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants