ugly repr() when using project layout with _my_ext_impl

[wojdyr]

I'm considering changing the layout of my project as advised in the docs:
https://nanobind.readthedocs.io/en/latest/packaging.html#step-1-overview

Currently, my module is a shared library, no directories and no python files.
The proposed layout has advantages, but if I adopt it and do:

from ._my_ext_impl import *

then this:

<my_ext.Dog object at 0x1044540f0>

becomes this:

<my_ext._my_ext_impl.Dog object at 0x1044540f0>

I could add def("__repr__") for each class, but that would be a lot of low-value functions.
Doing my_ext.Dog.__module__ = 'my_ext' also seems to work, although I'm not sure if it's a good idea.
Or I could just live with the ugly repr's.

Does anyone have a better solution?

[wjakob]

You could import the base module with nb::module_::import_() and then pass that module to the various nb::class_<> and m.def calls.

[wojdyr]

Thanks, it works on Linux and Mac. Unfortunately, on Windows CI (for any Python version I tried) it's seen as a circular import:

    File "C:\projects\gemmi\py\gemmi\__init__.py", line 2, in <module>
      from . import gemmi_ext
  ImportError: cannot import name 'gemmi_ext' from partially initialized module 'gemmi' (most likely due to a circular import)

[wjakob]

That's pretty weird. I do the same thing sometimes and haven't had such issues. Is it possible that your C++ binding code is triggering further imports or running code that can't work correctly with the in-progress import?

[wojdyr]

Yes, it's a problem with my build. A modified nanobind_example works fine.

For people finding it in the future, all that needs to be changed is this in C++:

-NB_MODULE(nanobind_example_ext, m) {
+NB_MODULE(nanobind_example_ext, m_unused) {
+    (void) m_unused;
+    nb::module_ m = nb::module_::import_("nanobind_example");

and import in __init__.py

-from .nanobind_example_ext import add, __doc__
+from . import nanobind_example_ext