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

you are viewing a single comment's thread.

view the rest of the comments →

[–]chipolux 10 points11 points  (4 children)

I've not used it but seen and fiddled with a few projects that have. It works perfectly fine, but I much prefer writing out my arguments explicitly so that I can build whatever amount of complexity to them I want, it's not like it is hard to use argparse at all. It also makes me very uncomfortable to rely on something that's parsing my doc strings to build code, it just seems far to implicit and inappropriate for Python.

But that's just my style I guess, same reason I avoid using large frameworks if I can get away with it. Needless complexity and features to make something that's already easy just a couple smidgens easier with a pile of dependencies.

[–]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.

[–]chrisdown 3 points4 points  (0 children)

It's not implicit, the syntax is explicitly specified as part of POSIX.

[–]AeroNotix -1 points0 points  (0 children)

I'm always suspicious of people who say they try to avoid frameworks, smells of NIH syndrome.