Skip to content

Conversation

@Icxolu
Copy link
Contributor

@Icxolu Icxolu commented Jan 18, 2026

This deprecates the tuple syntax for super class initialization as per #5739 (review).

In #[new] this will emit a deprecation warning when detected. As for the From<(S, B)> for PyClassInitializer<S> impl, I'm not sure we can do more that mentioning it in the changelog and migration guide.

@Icxolu Icxolu force-pushed the deprecate-super-init-from-tuple branch from 43a7cdd to eeb230c Compare January 18, 2026 22:08
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.

Thanks, this looks good to me. Some thoughts:

  • We should probably touch up the docs and guide to make it easier for users to understand how to use PyClassInitializer.
  • Should we be figuring out how to pass arguments to super __new__ before asking users to migrate existing code? I am not entirely sure we won't have to change the PyClassInitializer API to make that possible, and it might be unfortunate if we push users to use this API just for us to change it again.

To override this default, use the `extends` parameter for `pyclass` with the full path to the base class.
Currently, only classes defined in Rust and builtins provided by PyO3 can be inherited from; inheriting from other classes defined in Python is not yet supported ([#991](https://github.com/PyO3/pyo3/issues/991)).

For convenience, `(T, U)` implements `Into<PyClassInitializer<T>>` where `U` is the base class of `T`.
Copy link
Member

Choose a reason for hiding this comment

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

This doc needs updating, probably should just mention PyClassInitializer here.

| | **Cannot fail** | **May fail** |
|-----------------------------|---------------------------|-----------------------------------|
|**No inheritance** | `T` | `PyResult<T>` |
|**Inheritance(T Inherits U)**| `(T, U)` | `PyResult<(T, U)>` |
Copy link
Member

Choose a reason for hiding this comment

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

Should remove this too.

@Icxolu
Copy link
Contributor Author

Icxolu commented Jan 19, 2026

  • Should we be figuring out how to pass arguments to super __new__ before asking users to migrate existing code? I am not entirely sure we won't have to change the PyClassInitializer API to make that possible, and it might be unfortunate if we push users to use this API just for us to change it again.

Good question. I think this depends on how we want that API to look like. The simple solution would probably be to add something like PyClassInitializer::add_native_base_args and store them inside of the PyClassInitializer. I think this could work to provide that functionality, but I'm not sure if that's the best api we can come up with...

For example something like this:

impl<T: PyClass> PyClassInitializer<T> {
    ...

    pub fn add_args(mut self, args: Bound<'_, PyTuple>) -> Self
    where
        T::BaseType: PyClassBaseType<Initializer = PyNativeTypeInitializer<T::BaseType>>,
    {
        self.args = Some(args.unbind());
        self
    }
    
    pub fn add_kwargs(mut self, kwargs: Bound<'_, PyDict>) -> Self
    where
        T::BaseType: PyClassBaseType<Initializer = PyNativeTypeInitializer<T::BaseType>>,
    {
        self.kwargs = Some(kwargs.unbind());
        self
    }

    ...
}

And usage like this:

#[pyclass(subclass, extends=PyDict)]
struct Foo {}

#[pyclass(extends=Foo)]
struct Bar;

#[pymethods]
impl Bar {
    #[new]
    fn new(py: Python<'_>) -> PyClassInitializer<Self> {
        let args = todo!();
        PyClassInitializer::from(Foo {}).add_args(args).add_subclass(Bar)
    }
}

@Icxolu Icxolu force-pushed the deprecate-super-init-from-tuple branch from eeb230c to 820716e Compare January 23, 2026 21:12
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