Make writing modules simpler

[orowith2os]

Currently, with PyO3, it's quite simple to write functions that Python can use. However, it gets a bit weird when it comes to creating a module.

This is the current example:

use pyo3::prelude::*;

#[pyfunction]
fn double(x: usize) -> usize {
    x * 2
}

#[pymodule]
fn my_extension(py: Python<'_>, m: &PyModule) -> PyResult<()> {
    m.add_function(wrap_pyfunction!(double, m)?)?;
    Ok(())
}

You can see that the double function looks just like normal Rust, only with an added attribute macro. However, defining the my_extension module is a bit weirder. The syntax is a bit confusing and hard to write for each function you want to expose to Python.

This issue is about how to make it simpler to utilize; ideally, it would be as simple as something like this:

#[pymodule]
fn my_extension() {
    double();
}

Or something along those lines. This would benefit users of PyO3 greatly, especially when it comes to consistently using it in Python projects.

[davidhewitt]

Thanks for the proposal! I agree the #[pymodule] macro is overdue some ergonomic improvements.

What do you think about allowing #[pymodule] on mod items? For example, it might look like this:

#[pymodule]
mod my_extension() {
    #[pyfunction]
    fn double(x: usize) -> usize {
        x * 2
    }
}

Every #[pyfunction] and #[pyclass] inside the module could be automatically registered. We could also allow a #[module_init] function or similar to enable full customization like the function-modules we have today.

I started working on a draft of this in #2367, however I haven't found the time to continue with this. Help in design or implementation is always welcome.

[orowith2os]

What do you think about allowing #[pymodule] on mod items?

It looks great! I'd love to have this, especially in a large project; only having to add a #[pymodule] and #[pyfunction] would be nice, especially because chances are it's already all split up into modules.

[birkenfeld]

I started working on a draft of this in #2367, however I haven't found the time to continue with this. Help in design or implementation is always welcome.

As a first step, I rebased your work and added support for cfgs on the use items: #3294

[davidhewitt]

Closing in favour of #3900, which tracks the experimental-declarative-modules feature.