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
{{ message }}
Repository navigation
Template functionality for argument blocks using with_annotaed decorator #1689
To avoid redundant code, add a template mechanism for argument blocks that appear in multiple commands. Using the with_argparse decorator this is easy by reusing a function that modifies a parser; with_annotated currently has no simple equivalent.
Possible solutions
Use a TypedDict + Unpack to reuse a named block of annotations:
Allow attaching a predefined parser to the parser generated by with_annotated, and expose the resulting namespace inside the decorated method for easy access.
Both approaches reduce duplication; the second may be simpler to implement.
And the type resolution is checking for a dataclass type. It will likely need some extra constraints, such as being used only on the last argument or requiring something like the second example. This depends on what can go wrong.
Looks reasonable to me. I think your approach is better than simply using **kwargs: this also lets a user use multiple different argument blocks in the same method without merging them. I think this allows for a very clean design.
@KelvinChung2000 I'm thinking about putting out a release over the weekend. Would you like to address this or the other open issue prior to putting out the next release?
I have the feature mostly implemented. I will open the PR soon. It will address this and #1690, since this block feature provides a nice way to support typed args with parent argument inheritance.
Activity
KelvinChung2000 commentedon Jun 10, 2026
I prefer the
TypedDictapproach. I am considering a "template dataclass". So the use case becomes:And the type resolution is checking for a dataclass type. It will likely need some extra constraints, such as being used only on the last argument or requiring something like the second example. This depends on what can go wrong.
neoniobium commentedon Jun 11, 2026
Looks reasonable to me. I think your approach is better than simply using
**kwargs: this also lets a user use multiple different argument blocks in the same method without merging them. I think this allows for a very clean design.tleonhardt commentedon Jun 24, 2026
@KelvinChung2000 I'm thinking about putting out a release over the weekend. Would you like to address this or the other open issue prior to putting out the next release?
KelvinChung2000 commentedon Jun 24, 2026
I have the feature mostly implemented. I will open the PR soon. It will address this and #1690, since this block feature provides a nice way to support typed args with parent argument inheritance.