Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Implement exclusive groups. #112

Merged
merged 1 commit into from
May 30, 2024
Merged

feat: Implement exclusive groups. #112

merged 1 commit into from
May 30, 2024

Conversation

DanCardin
Copy link
Owner

@DanCardin DanCardin commented Apr 11, 2024

arg: Annotated[
    int,
    cappa.Arg(short="-v", action=cappa.ArgAction.count),
    cappa.Arg(long="--verbosity"),
] = 0

Is the proposed syntax for this so far. This might be nicer as X | Y, but that gets somewhat more magical implementation wise and it's not entirely clear that it's that much better, if at all.


What's unclear is whether this syntax is useful without also implying mutual exclusivity. I could imagine for an int target, --verbosity 3 -v might yield arg == 4. but ordering would become significant and most other types of inputs wouldn't make sense.

...granted this is essentially exactly how all of argparse's arguments work (unless there's validation i'm forgetting), relying on you to select metavars that dont conflict in stupid ways...

Ultimately, you'd still be able to opt out of the default behavior by explicitly setting exclusive_group=None, for whatever that's worth soooooo 🤷

@DanCardin DanCardin force-pushed the dc/exclusive-group branch 5 times, most recently from db1b0c1 to 142825c Compare April 16, 2024 01:20
@DanCardin DanCardin marked this pull request as ready for review April 16, 2024 01:21
@DanCardin
Copy link
Owner Author

In fact, it's significantly more difficult and ambiguous when allowing Annotated[int, Arg()] | Annotated[str, Arg()]. Namely, because parsing of values into their resultant types happens after parsing has completed, by which point it's too late to keep track of whether the int variant was selected or not.

And mapping happens after parsing because there are all sorts of reasons (prompts, Env, defaults, just as features. but also the split backends; deferring mapping to argparse was consistently a pain early on, caused code duplication and made it easy to have behavioral differences) why doing it at parse time is problematic.

It may still be possible...perhaps by scarily mutating the Args during parsing, or something I havent thought of yet, but i'm not yet certain whether it's a good enough idea to warrant the extra complexity.

Copy link

codecov bot commented May 30, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (cd24bfc) to head (6b4885e).
Report is 9 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #112   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           22        22           
  Lines         2012      2091   +79     
  Branches       442       462   +20     
=========================================
+ Hits          2012      2091   +79     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@DanCardin DanCardin merged commit 82427f1 into main May 30, 2024
9 checks passed
@DanCardin DanCardin deleted the dc/exclusive-group branch May 30, 2024 00:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant