generics

[hiaselhans]

From looking through some older issues and by trying i found that generics and custom traits are not supported by pyo3.

Is that something that is on the roadmap?
or is it an "impossible" issue?
I am used to using pybind11's interface which allows for py::class_ being defined in (templated) functions, making it easy to bind existing libraries. I think there is no counterpart in pyo3 and probably this is impossible too?

As one can use multiple-pymethods feature, i guess the best way to get close to generics would be to implement a macro to create several impl's at once and specialization after that. would that be possible?

[davidhewitt]

I don't think it's likely that

#[pyclass]
struct GenericType<T> {
    inner: T
}

will be a first-class PyO3 feature, at least not without some very well-written design proposal on how this should be treated.

The reason is that (I assume) each instantation GenericType<i32>, GenericType<f64> would have to have a different Python type object. This is an infinite set, and code would need to be generated for each instantiation. These would presumably have to be done manually as part of the #[pymodule] code. Even then, it's very much not clear how PyO3's implementation would do all this behind the scenes.

The best alternative, which works already, is to write a macro which expands to a new #[pyclass] for each instantiation you want.

To clarify, I'm willing to hear proposed additions to PyO3's API to support this. I just think it's a very hard problem to solve cleanly, and if it makes the core PyO3 code harder to maintain, I would want us to consider the tradeoff whether it's worth it when we already can write solutions using macros.

Similarly, it would be very cool to have a pybind11-style procedural API. I think in particular at the moment we're limited to using macros due to lack of variadic generics in Rust. That doesn't mean we can't have it, just that a direct port of the pybind11 API would not work. Contributions welcome to explore this.

[austin362667]

This is an infinite set, and code would need to be generated for each instantiation.

I agree with @davidhewitt . PyO3 shouldn't support first-class generics conversion without a carefully designed proposal.

[austin362667]

For our use case, I’m trying to implement PyClass for all our generated protobuf Rust code.

We encounter issues with generics while exposing gRPC service functions and helper functions for protobuf serialization and deserialization.

Our current workaround involves manually crafting macros to specify the concrete type for each known type, as the set of types is finite. However, this approach causes us to lose compile-time error messages.

I hope to find better approaches for this problem!