I wanted to improve on presentation, since my last post: http://news.ycombinator.com/submitted?id=halst
Great idea, great presentation!
Only thing different might be instead of giving the solution on that page itself - a hyperlink to the solution which takes you to docopt.org landing page
If I had just seen it presented straight out as, "Parse arguments based on docstrings," I doubt it would have been nearly as memorable.
Making possible several help-screens for different commands is on it's way. The only stopper—deciding on API: https://github.com/docopt/docopt/issues/17
But I'd strongly vote for making it possible to annotate multiple functions and merging their respective doc-strings smartly.
I don't think you'd want to express the entire syntax-tree of a reasonably complex program (e.g. 'git') in a single doc-string. Not only would that turn into a mess, but you'd also lose modularity. I.e. subcommands often need to be dynamically generated (e.g. depending on loaded modules) and not all subcommands may be available at all times.
Given the elegance of that very solution I think this marketing stunt is entirely unneeded and actually harmful; it's confusing and you miss out on getting a descriptive headline such as "Generate OptParser from code comment!".
That said... Brilliant idea!
I'm definitely trying out docopt for my next project.
And I have a counter-challenge for you:
How about making docopt work with nested commands? I.e. multiple methods could have a docopt-style comment and they would smartly merge to enable usages such as "mygit remote show --help", where 'show' is a subcommand of 'remote', with its own set of parameters and a matching help-page.
If you can work that one out then docopt could become the defacto standard for generating even complex OptParsers.