4 ms·

Armin, my feedback is in the form of my own version of this library.[1] I have been working on this on and off for some time and like you have not made a releas

by timtadh 12y ago

Armin, my feedback is in the form of my own version of this library.[1] I have been working on this on and off for some time and like you have not made a release. That said, I have been using it quite a bit both in my research and at work and I think it helps. The main idea behind it is make it easy to write a "getopt" style program with arbitrary command nesting. I have found that although argparse and sisters are nice libraries they don't allow me to do many of things I like to do in my interfaces. For instance sometimes like options such as foo -x a -x y -x q ... where I would process that into like so: extras = list() for opt, arg in opts: if opt in ('-h', '--help',): util.usage() ... elif opt in ('-x', '--extra'): extras.append(validate_or_die(arg)) I also believe that you should have "fast fail" validators. So I have several in `optutils` which are like: util.assert_dir_exists(path) which if a directory doesn't exist on the path it creates it. If there is already a file there and it isn't a directory it dies with an error. When it dies, I try and have unique exit codes for various errors (for testability) and provide usage information immediately. This style is nice because it provides immediate feedback to the user with no fuss. I think a lot of "option parser frameworks" miss the point in having lots of things for parsing ints and things. Most of the time I deal with files, directories, and "string" parameters which these libraries don't help with. In general, the standard libraries make it way to hard to write really nice command line tools. I like some things about your library, but I think that you need to increase the flexibitly for how options are processsed to you can do whatever you want with them. I also think that option parsing and configuration should be integrated. I am working to support that but I am not there yet. (see optutils/conf.py for my current ideas) [1] https://github.com/timtadh/optutils https://github.com/timtadh/optutils

masklinn 12y ago
> I have found that although argparse and sisters are nice libraries they don't allow me to do many of things I like to do in my interfaces. For instance sometimes like options such as ? This is trivial to do with argparse (or optparse for that matter): import argparse def a_prefixed(string): if not string.startswith('a'): raise argparse.ArgumentTypeError("%r does not start with 'a'" % string) return string parser = argparse.ArgumentParser() parser.add_argument('-x', '--extra', action='append', type=a_prefixed) print parser.parse_args() resulting in: > python test.py -x afoo -x abar Namespace(extra=['afoo', 'abar']) > python test.py -x afoo -x baz usage: test.py [-h] [-x EXTRA] test.py: error: argument -x/--extra: 'baz' does not start with 'a' > I also believe that you should have "fast fail" validators. Isn't that what the callback parameter is for, especially with is_eager=True? Or ParamType if you need either something more reusable or something more extensive. > Most of the time I deal with files, directories, and "string" parameters which these libraries don't help with. http://click.pocoo.org/api/#click.File http://click.pocoo.org/api/#click.File, argparse has something similar.
- timtadh 12y ago
  @masklinn good point. I haven't used argparse (mostly out of compatibility requirements with 2.6). So I may have mis-characterized the state of the art. It does do many things well. One note, is that the `prefix parsing` functionality could cause weird behavior when doing partial parsing (which I do a lot of). > Isn't that what the callback parameter is for, especially with is_eager=True? Or ParamType if you need either something more reusable or something more extensive. yes. I think almost everything should work like this. I think the getopt style makes this a bit easier to understand. > http://click.pocoo.org/api/#click.File http://click.pocoo.org/api/#click.File, argparse has something similar. Not at all the same. I never said my programs were going to open the files themselves. I often have to write automation scripts around other things. In these cases I need to make sure files and directories are sane but I don't open them. I just canonicalize them and pass them on. The big thing is the lack of integration with configuration files which is something I am still working on myself.

by timtadh 12y ago

masklinn 12y ago

> I have found that although argparse and sisters are nice libraries they don't allow me to do many of things I like to do in my interfaces. For instance sometimes like options such as ? This is trivial to do with argparse (or optparse for that matter): import argparse def a_prefixed(string): if not string.startswith('a'): raise argparse.ArgumentTypeError("%r does not start with 'a'" % string) return string parser = argparse.ArgumentParser() parser.add_argument('-x', '--extra', action='append', type=a_prefixed) print parser.parse_args() resulting in: > python test.py -x afoo -x abar Namespace(extra=['afoo', 'abar']) > python test.py -x afoo -x baz usage: test.py [-h] [-x EXTRA] test.py: error: argument -x/--extra: 'baz' does not start with 'a' > I also believe that you should have "fast fail" validators. Isn't that what the callback parameter is for, especially with is_eager=True? Or ParamType if you need either something more reusable or something more extensive. > Most of the time I deal with files, directories, and "string" parameters which these libraries don't help with. http://click.pocoo.org/api/#click.File http://click.pocoo.org/api/#click.File, argparse has something similar.

timtadh 12y ago
@masklinn good point. I haven't used argparse (mostly out of compatibility requirements with 2.6). So I may have mis-characterized the state of the art. It does do many things well. One note, is that the `prefix parsing` functionality could cause weird behavior when doing partial parsing (which I do a lot of). > Isn't that what the callback parameter is for, especially with is_eager=True? Or ParamType if you need either something more reusable or something more extensive. yes. I think almost everything should work like this. I think the getopt style makes this a bit easier to understand. > http://click.pocoo.org/api/#click.File http://click.pocoo.org/api/#click.File, argparse has something similar. Not at all the same. I never said my programs were going to open the files themselves. I often have to write automation scripts around other things. In these cases I need to make sure files and directories are sane but I don't open them. I just canonicalize them and pass them on. The big thing is the lack of integration with configuration files which is something I am still working on myself.