Skip to content
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

Documents experimental-declarative-modules feature #3953

Merged
merged 2 commits into from
Mar 13, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions guide/src/features.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,12 @@ This feature adds support for `async fn` in `#[pyfunction]` and `#[pymethods]`.

The feature has some unfinished refinements and performance improvements. To help finish this off, see [issue #1632](https://github.com/PyO3/pyo3/issues/1632) and its associated draft PRs.

### `experimental-declarative-modules`

This feature allows to declare Python modules using `#[pymodule] mod my_module { ... }` syntax.

The feature has some unfinished refinements and edge cases. To help finish this off, see [issue #3900](https://github.com/PyO3/pyo3/issues/3900).

### `experimental-inspect`

This feature adds the `pyo3::inspect` module, as well as `IntoPy::type_output` and `FromPyObject::type_input` APIs to produce Python type "annotations" for Rust types.
Expand Down
52 changes: 52 additions & 0 deletions guide/src/module.md
Original file line number Diff line number Diff line change
Expand Up @@ -105,3 +105,55 @@ submodules by using `from parent_module import child_module`. For more informati
[#1517](https://github.com/PyO3/pyo3/issues/1517#issuecomment-808664021).

It is not necessary to add `#[pymodule]` on nested modules, which is only required on the top-level module.

## Declarative modules (experimental)

Another syntax based on Rust inline modules is also available to declare modules.
The `experimental-declarative-modules` feature must be enabled to use it.

Copy link
Member

Choose a reason for hiding this comment

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

Should we briefly note what might be subject to change before we call this ready? I guess mostly it is the submodule automatically going to sys.modules and also the setting of #[pyclass(module = ....)].

We could also add a link to the issue.

(And I guess we thought we might change the attribute names, though I'm feeling quite happy about those.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done: 6b31c39

BTW, sorry for my English, as you can see it's not my native language

For example:
```rust
# #[cfg(feature = "experimental-declarative-modules")]
# mod declarative_module_test {
use pyo3::prelude::*;

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

#[pymodule]
mod my_extension {
use super::*;

#[pymodule_export]
use super::double; // Exports the double function as part of the module

#[pyfunction] // This will be part of the module
fn triple(x: usize) -> usize {
x * 3
}

#[pyclass] // This will be part of the module
struct Unit;

#[pymodule]
mod submodule {
// This is a submodule
}

#[pymodule_init]
fn init(m: &Bound<'_, PyModule>) -> PyResult<()> {
// Arbitrary code to run at the module initialization
m.add("double2", m.getattr("double")?)?;
Ok(())
}
}
# }
```

Some changes are planned to this feature before stabilization, like automatically
filling submodules into `sys.modules` to allow easier imports (see [issue #759](https://github.com/PyO3/pyo3/issues/759))
and filling the `module` argument of inlined `#[pyclass]` automatically with the proper module name.
Macro names might also change.
See [issue #3900](https://github.com/PyO3/pyo3/issues/3900) to track this feature progress.
Loading