Open martinjm97 opened 8 months ago
This suggestion about the doc string is very similar to the proposal in #93 which was rejected in favor of #98 (using a dataclass instead). IMO, the complexity of this suggestion may introduce sustainability problems in the long run.
I was hoping to use Annotated
to provide other metadata about the argument, like what version of my CLI introduced support for that argument. That way I can generate a better CLI doc from the Tap derivative's members' type metadata.
Tap currently gets the help strings from the comments:
However, https://docs.python.org/3/library/typing.html#typing.Annotated allows users to provide both a type and a comment. Using
Annotated
, the above code becomes:One edge case is whether or not we should ignore surrounding comments when an argument is annotated. We're thinking that whenever there's an annotation for an argument, we should ignore the surrounding comments. For example,
A potential issue with this design is that
Annotated
can be used to specify refinement types (e.g., that an argument is positivearg: Annotated[int, Gt(0)]
). A solution would be to have a customTap
class forHelpString
and then only use annotations when the annotation is of typeHelpString
. For example,would provide the help string, but
and
would not contribute to the command line help string.
Another thought is that we could potentially support verification as in
pydantic
.--JK