How do I make sphinx understand the documentation information in static methods?

[riclarsson]

Hi any and all,

We decided to switch from pybind11 to nanobind.

This is a growth pain question.

I have a problem getting my sphinx documentation for static data and static methods working in nanobind. In pybind11, static methods produces nice documentation.

You can see this comparing our stable new and stable documentation. This page gives the method get_options, where nanobind seems to think it returns an instance of some of itself, and pybind11 shows the documentation.

Note that if I go into ipython and simply ? on /pyarts.arts.options.SpeciesTagType.get_options: pyarts.arts.options.SpeciesTagType.get_options?, I get the correct documentation. It just doesn't seem to propagate to sphinx.

I am wondering if there are workarounds here so that sphinx can see the documentation?

[wjakob]

How do you list the classes and their members? Have you tried registering them explicitly, like so?

.. autoclass:: class

   .. automethod:: method

It's possible that Sphinx thinks that the static methods are data, not functions.

[wjakob]

If that doesn't do it, then I fear that this is something that only the Sphinx team can fix.

[riclarsson]

Thank you for the advice. The core problem is definitely how sphinx interprets what nanobind types are what type.

The jinja template we are using for generating the class data, which is just a standard template with nothing special in it, does not work with nanobind.

The main reason is that nanobind produces types that are not seen as methods, but as attributes. The link above, the nanobind types never sees the methods tab. As a consequence, sphinx believes it should be using the :autoattribute: command rather than the :automethod: command...

[wjakob]

Have you opening an issue with the Sphinx team? It should be easy to distinguish callable from non-callable objects and use this to display static methods correctly.

[riclarsson]

No, I did not report it.

I am not sure how to report this in a manner that is clear for them to reproduce. Nor if it is just our implementation of the template that is wrong.

I can identify the problem but my only solution has been to completely ignore the automatic code and to sweep through the generated library to manually call the right command depending on the types.