You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today most of the options dataclasses use the same Google style argument docstring as the rest of the modules. Unfortunately, the rendered API reference would list each field under both Parameters and Attributes, for example:
The one exception is SamplerExecutionOptions, which only has attribute docstring. The generated doc therefore only shows the fields under Attributes:
I think this is a much nicer format, as you get both the description and type in one place.
@Eric-Arellano please let us know if you have better ideas!
Acceptance criteria
Use attribute docstring instead of argument docstring for options classes.
Also note that when I played with SamplerExecutionOptions, the text Default: True was not formatted correctly, so I don't know if there is special convention on specifying defaults.
The text was updated successfully, but these errors were encountered:
What is the expected feature or enhancement?
Today most of the options dataclasses use the same Google style argument docstring as the rest of the modules. Unfortunately, the rendered API reference would list each field under both
Parameters
andAttributes
, for example:The one exception is SamplerExecutionOptions, which only has attribute docstring. The generated doc therefore only shows the fields under
Attributes
:I think this is a much nicer format, as you get both the description and type in one place.
@Eric-Arellano please let us know if you have better ideas!
Acceptance criteria
Also note that when I played with
SamplerExecutionOptions
, the textDefault: True
was not formatted correctly, so I don't know if there is special convention on specifying defaults.The text was updated successfully, but these errors were encountered: