-
Notifications
You must be signed in to change notification settings - Fork 927
deprecate super class initialization from tuples #5741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
43a7cdd to
eeb230c
Compare
davidhewitt
left a comment
There was a problem hiding this 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 thePyClassInitializerAPI to make that possible, and it might be unfortunate if we push users to use this API just for us to change it again.
guide/src/class.md
Outdated
| 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`. |
There was a problem hiding this comment.
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.
guide/src/class.md
Outdated
| | | **Cannot fail** | **May fail** | | ||
| |-----------------------------|---------------------------|-----------------------------------| | ||
| |**No inheritance** | `T` | `PyResult<T>` | | ||
| |**Inheritance(T Inherits U)**| `(T, U)` | `PyResult<(T, U)>` | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should remove this too.
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 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)
}
} |
eeb230c to
820716e
Compare
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 theFrom<(S, B)> for PyClassInitializer<S>impl, I'm not sure we can do more that mentioning it in the changelog and migration guide.