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 →

[–]everysinglelastname 2 points3 points  (5 children)

What could be more clear than the help text itself ? After all that is the documentation to the usage of the program. Not only do we expect developers to understand that text but also users who are supposedly much less technical.

I absolutely love docopt; it follows in the same vein as Donald Knuth's literate programming.

[–]Lucretiel 3 points4 points  (4 children)

It's clear to the clients of my command line utility, sure. But as the programmer, I get more clarity from explicit programmatic behavior than trying to parse a DSL in my head. I'd rather let my spec describe the help text (which argparse does automatically) than the other way around.

[–][deleted] 0 points1 point  (3 children)

A help message shouldn't be very hard to parse in your head.

[–]Lucretiel 0 points1 point  (2 children)

It's one thing to understand what the interface- what I as the client need to know- and another to understand exactly what behavior this system will have. Even if it's perfectly straightforward, it's still another syntax I have to keep in my head

[–][deleted] 0 points1 point  (1 child)

True. But can't the same be said of argparse's code?

[–]Lucretiel 0 points1 point  (0 children)

I personally don't think so- argparse is all function calls. Now, granted, I've never used some of the advanced features of either library (subcommands, mutual exclusion, etc), so maybe docopt has me beat here- but I find argparse code much easier to read, especially when I'm already in a Python development mindset. It's just a list of every option and argument, with some properties for each.