Skip to content

Conversation

@Icxolu
Copy link
Contributor

@Icxolu Icxolu commented Jan 17, 2026

This refactors the code generation for #[new] / pyclass initialization. It uses the same const probe trick we already use elsewhere in the macro machinery to dispatch the initialization based on the return type of the #[new] function. This removes the Existing case from the PyClassInitializer, making it easier to solve passing arguments to the base __new__ in a followup. Additionally it allows to return arbitrary object implementing IntoPyObject from __new__ which also takes over the Existing case.

Closes #3291
Closes #4452

Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

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

Very nice, thank you!

#text_signature_impl

use #pyo3_path::impl_::callback::IntoPyCallbackOutput;
use #pyo3_path::impl_::pyclass::Probe as _;
Copy link
Member

Choose a reason for hiding this comment

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

Often we need an unused_imports allow on here when the probe is positive, maybe need to add to this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I this case one of the probes will always be negative (PyClassInitializer<T> and initializer tuple will never implement PyClass), so I think the trait will always be used here.

@davidhewitt davidhewitt mentioned this pull request Jan 18, 2026
@Icxolu
Copy link
Contributor Author

Icxolu commented Jan 18, 2026

Maybe a side question: The tuple initializer could be a bit confusing now that we allow arbitrary object (I also always forget which order Subclass and Baseclass should have). Should we consider deprecating that syntax and move people to use PyClassInitializer directly?

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.

Soundness issue: users can create out-of-bounds reads and writes using PyClassInitializer Allow #[new] to return arbitrary objects

2 participants