On Fri, Nov 22, 2013 at 8:30 PM, guns <s...@sungpae.com> wrote: > On Fri 22 Nov 2013 at 07:22:20PM -0500, John Szakmeister wrote: > >> This looks very nice. Have you considered something along the lines >> of Python's argparse? >> >> http://docs.python.org/dev/library/argparse.html > > Thank you. I am not familiar with Python's argparse. My experience with > option parsers are primarily the C functions getopt and getopt_long, the > getopts builtin in bash, and Ruby's OptionParser. > > On first scan, argparse and OptionParser appear to be very similar, > both in capability and programming interface. I know OptionParser > particularly well, and while I enjoy its flexibility and power, the > actual implemention and scope of what it tries to accomplish are quite > un-Clojuresque.
Sorry, I didn't mean to suggest you should model the inteface after argparse. That said, I think there's much about it that's declarative and would fit well. > The beautiful thing about tools.cli is that it is conceptually very > simple: it reduces an option specification and a list of arguments into > a map of configuration options. Yep, and I think that's good as well. > IMHO, printing elaborate usage banners, associating subcommands with > methods, managing options of subcommands, and invoking behaviour should > be handled separately from option parsing. The guiding principle of > optparse-clj and the next version of tools.cli is to provide data and > let the user take it from there. The one thing that makes argparse interesting from everything else is that it gives all the nice handling to arguments as well. I can see from the examples you've got things like :parse-fn for parsing the argument and turning it into something else. It's nice to have those features for arguments as well, and that's where I think argparse is really shines. It treats both options and arguments as first-class citizens. :-) I think that would be useful for your library as well. >> It's nice to see you thought about subcommand support as well. Thank >> you for your contribution! > > The gist I linked to earlier¹ contains a detailed proposal for how I'd > like to advance tools.cli. If you are interested, comments on that are > much appreciated. I'll take a look at it over the weekend. Thanks! -John -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
