feat(dispatcher): constrained global arguments #220
Conversation
lengau
force-pushed
the
constrained-global-args
branch
2 times, most recently
from
6011c94
to
84e951b
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #220 +/- ##
==========================================
+ Coverage 93.24% 94.85% +1.61%
==========================================
Files 7 8 +1
Lines 1080 1107 +27
Branches 200 211 +11
==========================================
+ Hits 1007 1050 +43
+ Misses 66 53 -13
+ Partials 7 4 -3 ☔ View full report in Codecov by Sentry. |
lengau
force-pushed
the
constrained-global-args
branch
from
84e951b
to
02deb38
Compare
lengau
force-pushed
the
constrained-global-args
branch
from
b5c8b5b
to
499ed14
Compare
| validator=lambda mode: EmitterMode[mode.upper()], | ||
| case_sensitive=False, |
There was a problem hiding this comment.
choices also exists in argparse, will validator and case_sensitive options increase the gap between global argument handling and command-specific argument handling instead of reducing it? Ideally we should have an uniform way to handle all arguments.
There was a problem hiding this comment.
validator is equivalent to argparse's type - I can rename if you'd like.
case_sensitive is different, but is there for backwards compatibility in the way we handle --verbosity, which was previously case-insensitive due to special handling. Looking over it again, I wonder if I could just run the validator before limiting choices and make a special verbosity_validator function that returns the correct emitter mode.
Fixes #219
tox?