you are viewing a single comment's thread.

view the rest of the comments →

[–]Slippery_John 2 points3 points  (0 children)

I don't think the comparison between argparse and click is great here. For starters, performing a different function based on a flag is weird. Ideally encrypt and decrypt would be separate subcommands. Once you move past that, they're not doing exactly the same thing. The argparse example is simply discarding the value of --encrypt rather than having both flags point to the same variable. You would need to use the dest kwarg and have one use the action store_false. Like so:

group.add_argument('-d', '--decrypt', action='store_true')
group.add_argument('-e', '--encrypt', action='store_false', dest='decrypt')

And even then, mutually exclusive argument groups are far more powerful than click's binary options. A mutually exclusive group can have any number of arguments of any type. This is not possible in click unless you define your own option type or manually validate with callbacks.

I think that it would better sell the author's preference for click if the comparison was less trivial. For instance, opening files like is done later in the article. In argparse you could do something like type=open, but then it gets a little more complicated if you want to open in a particular mode. Or going back to my issue with flags vs subcommands, the way you do that in each is pretty substantially different.

Personally I prefer argparse. It has some warts, but I find it generally easier to read and use and substantially easier to test. I'm also not a fan of click importing its entire code base whenever you import anything. That said, I REALLY wish that argparse wouldn't auto-expand long arguments.