Typer by requires list options to be provided as --flag a --flag b --flag cinstead of --flag a b c as it was in the old interface. We now circumvented this issue.
Typer inherits this behavior from click, which does it like this to prevent ambiguity (the following section is LLM-generated):
cmd --items A B output.txt
cmd --items A --other B C
cmd --items -1 -2 --flag
Are output.txt, C, or -1 list values, positional args, or malformed options? Argparse allows this style with nargs='+', but it comes with edge cases around ordering, positionals, negative-looking values, and “greedy” consumption.
Click’s design is more conservative:
An option can take one value by default.
An option can take a fixed number of values, e.g. --range 1 10.
An option can be repeated for arbitrary lists, e.g. --model A --model B.
Unlimited space-separated values are reserved for positional arguments, where greediness is expected.
Typer inherits that. It favors unambiguous parsing and shell-like composability over argparse’s nargs='+' option behavior.
-> Maybe at some point we might want to make the switch to more robust argument handling
Originally posted by @nictru in #411 (comment)
Typer by requires list options to be provided as
--flag a --flag b --flag cinstead of--flag a b cas it was in the old interface. We now circumvented this issue.Typer inherits this behavior from click, which does it like this to prevent ambiguity (the following section is LLM-generated):
Are output.txt, C, or -1 list values, positional args, or malformed options? Argparse allows this style with nargs='+', but it comes with edge cases around ordering, positionals, negative-looking values, and “greedy” consumption.
Click’s design is more conservative:
An option can take one value by default.
An option can take a fixed number of values, e.g. --range 1 10.
An option can be repeated for arbitrary lists, e.g. --model A --model B.
Unlimited space-separated values are reserved for positional arguments, where greediness is expected.
Typer inherits that. It favors unambiguous parsing and shell-like composability over argparse’s nargs='+' option behavior.
-> Maybe at some point we might want to make the switch to more robust argument handling
Originally posted by @nictru in #411 (comment)