Not showing docs when PyO3 registers a struct with a different name

[elbaro]

My PyO3 module exposes a Rust struct in two places:

# mylib.SyncConn
m.add_class::<SyncConn>()?;

# mylib.sync.Conn
let sync = PyModule::new(py, "sync")?;
sync.add("Conn", py.get_type::<SyncConn>())?;
m.add_submodule(&sync)?;

pdoc correctly shows the class members of SyncConn not sync.Conn:

As a workaround, I manually assigned an instance of pdoc.doc.Class to the other.
This works if I want to show the full class members in both places, but if I want to customize them differently, I cannot deepcopy pdoc.doc.Class.

all_modules["pyro_mysql.sync"].members["Conn"] = copy.deepcopy(
        all_modules["pyro_mysql"].members["SyncConn"]
    )

all_modules["pyro_mysql"].members[
    "SyncConn"
].docstring = "See `pyro_mysql.sync.Conn`."
all_modules["pyro_mysql"].members["SyncConn"].own_members = []
all_modules["pyro_mysql"].members["SyncConn"].methods = []
all_modules["pyro_mysql"].members["SyncConn"].staticmembers = []
all_modules["pyro_mysql"].members["SyncConn"].classmembers = []

System Information

pdoc: 15.0.4
Python: 3.14.0rc2

[mhils]

I think this is because your class' __name__ is SyncConn and not Conn, which triggers a heuristic for static class attributes (#464). I suppose we could fine-tune the heuristic a bit, but generally speaking I'd just recommend to not expose classes under different names. Aside from pdoc, that's always going to be a can of worms in Python.

[hiSandog]

This seems like a good place for a focused docs example: show the smallest setup that demonstrates “Not showing docs when PyO3 registers a struct with a different name”, then state the expected output or UI state. That would make the SyncConn case testable for users instead of leaving it as a general note.