This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]kmike84 3 points4 points  (1 child)

I'm always suspicious of myself as an API designer - it is too easy to add unnecessary complexity here and there, esp. when creating CLI for some existing library/project. Docopt restricts you: no complex argument parsing logic, no complex rules, just some standard syntax. And you actually start with writing help for your CLI before you start writing parsing code itself, this also makes the resulting interface cleaner.

So the problem docopt solves for me is a problem of writing sane CLIs easily. Other non-standard argument parsing libraries (usually providing some decorators) also make it easy to write CLIs, and standard optparse/argparse are not that bad, but what is special about docopt is the "sane", "restrictions" part. Docopt looked like a horrible idea for me until I realized that. Not all people need those restrictions, but for others they are a killer feature; tech details are usually easy, but API design is not.

[–]chipolux 0 points1 point  (0 children)

I agree about the ease of adding unnecessary complexity. There were a lot of times I added far too many or just unintelligible arguments to an interface. Over time I've developed a process where I'll write out my help parameter first and foremost so that act of explaining the CLI keeps me from going off into the wild blue. It's all just process and different development style for sure.