I can't stand argparse. It's like they tried their hardest to force you to be imperative and prevent composability. For example, instead of being able to define a parser for a subcommand and build a top-lever parser from that, you need to do this:
parser = argparse.ArgumentParser()
subparsers = parser.add_subparsers()
a = subparsers.add_parser('a')
a.add_argument('bar')
A better API would look more like this:
Parser(Subparsers({
'a': Parser(Arg('bar')),
}))
On top of that it has a number of bugs in edge cases they refuse to document or fix. For example, you can't have a subcommand that always collects all the remaining arguments as-is. That's a pretty basic use-case when you want to pass those arguments to another program.
./example a arg1 arg2 arg3
./example a -- arg1 --look-ma-hyphens-arg2 arg3
If you're complaining about the double hyphen syntax....that's a universal convention for UNIX-ish CLI positional arguments. Otherwise things get really murky.
./example a --help
Did I want help on the `a` subcommand, or did I want to pass `--help` to the `a` subcommand? The `--` syntax lets you distinguish.
> Python is indeed an imperative language, along with the others I listed.
JavaScript has functional origins, and in practice quite a bit of JavaScript is written in a functional-lite style. As a JS developer, I find it quite infuriating that Python doesn't support these patterns, as they make code a lot more readable, and it seems to be a matter of principle rather than a technical limitation.
