Automatically treat nested modules as submodules #4308
Conversation
alex
force-pushed
the
auto-submodule
branch
2 times, most recently
from
a3005a5 to
efebf51
Compare
|
(This ended up being way simpler than I realized now that we support |
| @@ -237,6 +237,7 @@ pub fn pymodule_module_impl( | |||
| )? { | |||
| set_module_attribute(&mut item_mod.attrs, &full_name); | |||
| } | |||
| item_mod.attrs.push(parse_quote!(#[pyo3(submodule)])); | |||
There was a problem hiding this comment.
I think this needs some additional tests.
If submodule is already present, will this error? Probably it will error for duplicate submodule setting already, the error message should ideally read "submodules of declarative modules don't need submodule attribute set".
We might want to allow for submodule = false or maybe #[pymodule(importable)] to allow turning this off. Maybe? (TBH I can't see a use case where users would want to nest declarative modules and then allow both to be importable as root modules too.)
There was a problem hiding this comment.
Yeah I cannot think of a valid use case for that scenario. If one does want it, it can be accomplished by declrating two top-level modules and exporting one into the other.
|
Added a test case for the compilation error. When you say backwards incompatible, are you referring to removing the Either way, I can wait on this, since we can just manually mark things as submodules. |
fixes #4286