Class module name default

[aviramha]

Hi,
I'm deeply annoyed by the fact that if you declare a module using the #[pyclass] macro the module name of the class is builtins.
I looked in the code and I understand why it's a bit problematic.
At first I thought adding the module name to PyTypeInfo::type_object_raw then it could propagate to the class definition where it can use the module name.
I assume that's a bad practice as it's not part of the creation really..
Another thought I had in mind is to create a trait for get_module_name with a default implementation, then have a macro for adding a class into a module where it impls the trait.

Any feedback is welcome :)

[davidhewitt]

I agree that builtins is very annoying. You can use #[pyclass(module = "xyz")] to override this.

Also, I was thinking that with the future module syntax proposed in #694 (comment) it should become easy for us to automatically set the correct module name for the pyclass.

[aviramha]

Yes I am aware of the #[pyclass(module =..)] feature
The syntax proposal looks good. Could it be a milestone for 0.15?

[davidhewitt]

I would really like to introduce it as part of 0.15, yes. I'd love to build it myself eventually, however if anyone's interested in picking it up it'd be a very welcome addition!

The way I was thinking of introducing it was that we'd continue to accept the existing #[pymodule] syntax for now; this would be a new code path which triggers when putting #[pymodule] on top of a Rust module.

[aganders3]

Is this possibly a good “first timer” contribution? I’d love to get involved in this project but am a relative beginner in Rust and don’t want to bite off more than I can chew.

[davidhewitt]

Sorry for my slightly slow reply - I see you have started looking into the CI test failures, which is really appreciated. This issue is not the easiest, because the new #[pymodule] syntax will have a lot of design complexity and involve a lot of new proc macro code. If you're not afraid to dive in then I can offer some mentoring!

Alternatively I can try to mark some issues with a label which suggests what's good to start with?

[aganders3]

No worries! Thanks for the thoughtful response.

I'm not afraid to dive in but must admit I don't have experience with proc macros (yet) so I'm probably not the most efficient person to implement this. If there are better places to start I'd love some direction if/when you can find some time to label them. In the meantime I will keep an eye on the issues and just keep trying to familiarize myself with the code a bit more.

[davidhewitt]

For anyone looking, I began drafting an implementation in #2367 but haven't had time to finish it off. I do hope to get it over the line before too much more time passes!

[davidhewitt]

Closing, will track this as part of #3900