3 ms·

Really awesome and promising idea, but I think the implementation is limiting. Couldn't it just as well parse help text? It's not guaranteed to be standard, b

by nilved 12y ago

Really awesome and promising idea, but I think the implementation is limiting. Couldn't it just as well parse help text? It's not guaranteed to be standard, but there are probably more programs that can be parsed that way than use ArgumentParser.

wickawic 12y ago
http://docopt.org/ http://docopt.org/ This project attempted to make argument parsing and the help string synonymous. I'm not sure if it is being actively maintained.
- T-A 12y ago
  Nice find! https://github.com/docopt/docopt.go https://github.com/docopt/docopt.go was updated 18 days ago, so it does look alive and well.
- the_mitsuhiko 12y ago
  The problem with docopt is that it's very hard to process internally. There is no real internal representation. I tried to write a docopt to click converter but I had to give up.
  - ridiculous_fish 12y ago
    I'm not sure quite what you're looking for, but you may be interested in my (not yet announced) docopt parser in C++: https://github.com/ridiculousfish/docopt_fish https://github.com/ridiculousfish/docopt_fish . It's got a richer feature set than the "reference" docopt.
goostavos 12y ago
I actually started out just parsing the help text, but ArgParse gives a ton of extra options that let me better choose the widget type. For instance, things like `Choice` or `Count` options which cue the framework to use dropdowns. Or `StoreTrue` which cues it to generate a CheckBox. Stuff like that. I'm not totally sure how I could get that level of detail without forcing some kind of markup within the help messages. I'm totally open to ideas (and pull requests) though! :)
- michaelmior 12y ago
  I haven't looked at the code, but have you thought about abstracting out the bits that deal with argparse? Then people could write adapters for optparse, docopt, etc. Hooking into argparse the way you do is super cool, but it would be nice not to be limited to that.

by nilved 12y ago

wickawic 12y ago

http://docopt.org/ http://docopt.org/ This project attempted to make argument parsing and the help string synonymous. I'm not sure if it is being actively maintained.

T-A 12y ago
Nice find! https://github.com/docopt/docopt.go https://github.com/docopt/docopt.go was updated 18 days ago, so it does look alive and well.
the_mitsuhiko 12y ago
The problem with docopt is that it's very hard to process internally. There is no real internal representation. I tried to write a docopt to click converter but I had to give up.
- ridiculous_fish 12y ago
  I'm not sure quite what you're looking for, but you may be interested in my (not yet announced) docopt parser in C++: https://github.com/ridiculousfish/docopt_fish https://github.com/ridiculousfish/docopt_fish . It's got a richer feature set than the "reference" docopt.

goostavos 12y ago

I actually started out just parsing the help text, but ArgParse gives a ton of extra options that let me better choose the widget type. For instance, things like `Choice` or `Count` options which cue the framework to use dropdowns. Or `StoreTrue` which cues it to generate a CheckBox. Stuff like that. I'm not totally sure how I could get that level of detail without forcing some kind of markup within the help messages. I'm totally open to ideas (and pull requests) though! :)

michaelmior 12y ago
I haven't looked at the code, but have you thought about abstracting out the bits that deal with argparse? Then people could write adapters for optparse, docopt, etc. Hooking into argparse the way you do is super cool, but it would be nice not to be limited to that.