The only way of getting undocumented constants defined in the module into the documentation seems to be to explicitly define:
.. py:data:: SOMECONST
It would be less surprising if :undoc-members: option to automodule sucked in undocumented constants as well.
Certainly, module global variables not having docstring is not documented even if :undoc-members:.
Wow, this issue was created in 2012. Are there any plans of making sure undocumented constants make it to the doc when using :undoc-members:
?
While six years, nobody had not tried to fix this. How about you? PR is always welcome :-)
haha! guess no one has been lazy enough to complain about having to doc their constants
On Sep 1, 2018, at 12:50 AM, Takeshi KOMIYA notifications@github.com wrote:
While six years, nobody had not tried to fix this. How about you? PR is always welcome :-)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
Ok @tk0miya, see #5387.
@tk0miya, do you know how I could differentiate from objects defined in the module between those imported? That was the roadblock I hit whilst implementing a solution for this ticket in #5387.
AFAIK, there are no way to investigate it. All classes and functions have __module__ attribute indicates where the object defined. But instances does not have it.
I guess our pycode module (sphinx.pycode) help it.
I'll take a look after releasing 1.8.0.
Thank you for your help.
You can work around this by adding your constants to __all__. This is tedious though.
Fixed by #6423 .
Thank you for reporting.
Reopened now. Because #6423 causes some troubles. I'll try this again in future version.