Quality of life macro for generic functions

[iliya-malecki]

Hello there! im currently using something like this in my project (please ignore the specifics, i want to share the general idea without ripping it out of the context that sparked the idea):

macro_rules! concrete_ordinal_encoding {
    ($typename: ident, $pymodule: ident) => {
        paste::item! {
            #[pyfunction]
            fn [< ordinal_encoding_$typename >]<'py>(py: Python<'py>, labels: Vec<$typename>) -> &'py PyArray1<usize> {
                ordinal_encoding(labels).into_pyarray(py)
            }
            $pymodule.add_function(wrap_pyfunction!([< ordinal_encoding_$typename >], $pymodule)?)?;
        }
    };
}

So, naturally, i wondered: is it a good idea to turn it into some sort of concrete_function!() macro to specialize generic functions to interface with python? on the python side, it could be implemented with an object with __getitem__ or __getattr__ to resolve what specific function to call. Do you think it is worth a dependency? Do you think this approach smells nice enough to be included in pyo3?

[davidhewitt]

Hello! Sorry to have been slow to reply.

This is an interesting idea, here's a few of my initial reactions:

• I am open to people exploring this design space. I don't yet have a good intuition for what feels nice so it might take some time before anything is merged in PyO3. While this is experimental it might be best to be a separate crate because it'll be easier to iterate.
• Choosing the set of types to instantiate the generic code with will be the hardest part of this design. I'm not sure if there's a way for users to do any better than just hard code a list of types for every function
• I think it'll be easier to agree on what we want the resulting Python API to look like, so might as well start there.
• if possible, I think it'd be nicer if this was a part of #[pyfunction] rather than a separate macro, but that'll very much depend on the design which emerges.

[Dan-wanna-M]

I think we probably want the python side to have a 'generic' function which dispatches to Rust binding function. Otherwise, I feel like we are not really saving much boilerplates. This is also closer to 'generic' semantics. This naturally means we want to monophize for every type parameter as well. I am not sure whether publicly exposing these monophizations yo Pytjon is a good idea though.