argparse - Project Hosting on Google Code

Last 7 days Dec 15, 2009 issue 50 (convention for reporting program name and version by default) changed by steven.bethard - This is definitely doable, since the output format would only change when the new fullname= argument was supplied. I'll try to add this for the next release, though if you're feeling ambitious, feel free to produce a patch yourself, and I'll review it. Status: Accepted Labels: Type-Enhancement −Type-Defect This is definitely doable, since the output format would only change when the new fullname= argument was supplied. I'll try to add this for the next release, though if you're feeling ambitious, feel free to produce a patch yourself, and I'll review it. Status: Accepted Labels: Type-Enhancement −Type-Defect Dec 15, 2009 issue 51 (improve exception messages for optparse related errors) reported by steven.bethard - Warn about string types in add_argument instead of parse_args: >>> parser = argparse.ArgumentParser() >>> parser.add_argument('foo', type='int') >>> parser.parse_args(['X']) usage: [-h] foo : error: argument foo: 'int' is not callable Warn about using optparse-style %prog formatting: >>> import argparse >>> parser = argparse.ArgumentParser() >>> parser.add_argument('foo', help='%prog') >>> parser.print_help() Traceback (most recent call last): ... ValueError: unsupported format character 'p' (0x70) at index 1 Warn about string types in add_argument instead of parse_args: >>> parser = argparse.ArgumentParser() >>> parser.add_argument('foo', type='int') >>> parser.parse_args(['X']) usage: [-h] foo : error: argument foo: 'int' is not callable Warn about using optparse-style %prog formatting: >>> import argparse >>> parser = argparse.ArgumentParser() >>> parser.add_argument('foo', help='%prog') >>> parser.print_help() Traceback (most recent call last): ... ValueError: unsupported format character 'p' (0x70) at index 1 Dec 15, 2009 issue 50 (convention for reporting program name and version by default) reported by techtonik - Neither optparse not argparse 1.0.1 provide user friendly reporting of program name and version by default. I propose the following convention to be supported by argument parsing library by default. 1. When user calls script.py without arguments the following information is displayed > script.py Full Program Name, version XXX Usage: script.py <...> Short Description Options: ... > script.py --version Full Program Name, version XXX {version template if present with license info or script doc block or ...} What is the expected output? What do you see instead? There is `prog` argument to ArgumentParser() that allows to specify script name in `"usage: ..."` line, but no argument to specify full program name. --version outputs just a number that is not sufficient. In most cases I would also like to see revision (as user) or display copyright (as developer) or just module docblock that contains both. Please provide any additional information below. It would be nice if argparse could stick to this default output if both 'version' and 'fullname' information is present and allow to customize templates before usage, usage itself, short description and options. Take a look at 'hg' (or 'svn') command line interface for an example of this approach. Neither optparse not argparse 1.0.1 provide user friendly reporting of program name and version by default. I propose the following convention to be supported by argument parsing library by default. 1. When user calls script.py without arguments the following information is displayed > script.py Full Program Name, version XXX Usage: script.py <...> Short Description Options: ... > script.py --version Full Program Name, version XXX {version template if present with license info or script doc block or ...} What is the expected output? What do you see instead? There is `prog` argument to ArgumentParser() that allows to specify script name in `"usage: ..."` line, but no argument to specify full program name. --version outputs just a number that is not sufficient. In most cases I would also like to see revision (as user) or display copyright (as developer) or just module docblock that contains both. Please provide any additional information below. It would be nice if argparse could stick to this default output if both 'version' and 'fullname' information is present and allow to customize templates before usage, usage itself, short description and options. Take a look at 'hg' (or 'svn') command line interface for an example of this approach. Dec 13, 2009 issue 49 (optparse incompatibilities are unnecessary) commented on by steven.bethard - Some other things you'd need to patch to make the transition seamless: * parse_args() would need to return something that can be unpacked into (args, []) * all the type= arguments would have to accept string forms as well I'm open to patches, but I'd want to have some folks verify that it really does make the transition easier before I commit the patch. Some other things you'd need to patch to make the transition seamless: * parse_args() would need to return something that can be unpacked into (args, []) * all the type= arguments would have to accept string forms as well I'm open to patches, but I'd want to have some folks verify that it really does make the transition easier before I commit the patch. Dec 13, 2009 issue 49 (optparse incompatibilities are unnecessary) reported by ianbicking - The use of methods like "add_argument" and "ArgumentParser" are unnecessarily different than optparse. I don't see a reason I shouldn't be able to replace "from optparse import ..." with "from argparse import ...", so long as I don't do anything particularly complicated (like add new converters). These small name changes get in the way of that. Also the optparse substitutions (like %prog) should be supported; it would only be a couple of lines of extra code to support both those and the current argparse %()s substitutions. The use of methods like "add_argument" and "ArgumentParser" are unnecessarily different than optparse. I don't see a reason I shouldn't be able to replace "from optparse import ..." with "from argparse import ...", so long as I don't do anything particularly complicated (like add new converters). These small name changes get in the way of that. Also the optparse substitutions (like %prog) should be supported; it would only be a couple of lines of extra code to support both those and the current argparse %()s substitutions. Dec 13, 2009 issue 43 (--help and --version methods; change defaults) commented on by steven.bethard - Done. I wasn't able to get either of the links you sent to work, but I did get a Vizu poll working. It's on the front page now: http://code.google.com/p/argparse/. We'll see if we get any votes. Done. I wasn't able to get either of the links you sent to work, but I did get a Vizu poll working. It's on the front page now: http://code.google.com/p/argparse/. We'll see if we get any votes. Last 30 days Dec 12, 2009 issue 43 (--help and --version methods; change defaults) commented on by techtonik - The real solution would be to put available variants to voting. Any gadgets for that issue on the front page? http://www.google.com/ig/directory? type=gadgets&url=www.gebweb.net/gadgets/VoteMate/VoteMate.xml http://www.google.com/ig/directory?url=echo3.net/poll/poll.xml The real solution would be to put available variants to voting. Any gadgets for that issue on the front page? http://www.google.com/ig/directory? type=gadgets&url=www.gebweb.net/gadgets/VoteMate/VoteMate.xml http://www.google.com/ig/directory?url=echo3.net/poll/poll.xml Dec 08, 2009 issue 43 (--help and --version methods; change defaults) commented on by steven.bethard - I wonder if the real solution here is to deprecate the version= keyword argument entirely, since everyone seems to have a different thing they want it to do. I wonder if the real solution here is to deprecate the version= keyword argument entirely, since everyone seems to have a different thing they want it to do. Dec 08, 2009 issue 43 (--help and --version methods; change defaults) commented on by techtonik - As a voice from Python community I dislike implicit default "-V" and "-v" shortcuts for --version. The proposed patch to treat "-v" implicitly as version if explicit "-v" is not defined also makes thing more complicated than they need to be. If version could be displayed along with program name in usage by default then you won't need any "shortcuts" for frequent calls to --version. As a voice from Python community I dislike implicit default "-V" and "-v" shortcuts for --version. The proposed patch to treat "-v" implicitly as version if explicit "-v" is not defined also makes thing more complicated than they need to be. If version could be displayed along with program name in usage by default then you won't need any "shortcuts" for frequent calls to --version. Dec 06, 2009 issue 48 (inconsistent --option=xxx vs --option xxx) Status changed by steven.bethard - Thanks for the bug report. Fixed in r79. >>> parser = argparse.ArgumentParser() >>> parser.add_argument('--si') >>> parser.add_argument('--size') >>> parser.parse_args(['--si=64']) Namespace(si='64', size=None) >>> parser.parse_args(['--si', '64']) Namespace(si='64', size=None) Status: Fixed Thanks for the bug report. Fixed in r79. >>> parser = argparse.ArgumentParser() >>> parser.add_argument('--si') >>> parser.add_argument('--size') >>> parser.parse_args(['--si=64']) Namespace(si='64', size=None) >>> parser.parse_args(['--si', '64']) Namespace(si='64', size=None) Status: Fixed Dec 06, 2009 r79 (Fix bug where --si=64 was deemed ambiguous when both --si an...) committed by steven.bethard - Fix bug where --si=64 was deemed ambiguous when both --si and --size were in the parser. Fix bug where --si=64 was deemed ambiguous when both --si and --size were in the parser. Dec 06, 2009 issue 46 ('-' should be a valid flag) commented on by sgustafso - Just the former. I could see too much confusion easily arising from the use if there wasn't a space in-between. Mostly I just want to be able to treat it as a standalone bool flag or as the key to a subparser. I've used both forms in my scripts, but the subparser form is probably more common. Just the former. I could see too much confusion easily arising from the use if there wasn't a space in-between. Mostly I just want to be able to treat it as a standalone bool flag or as the key to a subparser. I've used both forms in my scripts, but the subparser form is probably more common. Dec 06, 2009 issue 47 (optional subparsers) Labels changed by steven.bethard - I'm certainly open to such a feature. Patches are welcome. :) To make this work we'd have to teach _SubParsersAction to accept nargs='?'. This is a little complicated because currently _SubParsersAction tells the parser that it wants to consume everything else by passing nargs=PARSER. So we'd need some sort of nargs=PARSER_OR_NOTHING and the corresponding code everywhere that nargs is used. Perhaps there's an easier way though... Labels: Type-Enhancement −Type-Defect I'm certainly open to such a feature. Patches are welcome. :) To make this work we'd have to teach _SubParsersAction to accept nargs='?'. This is a little complicated because currently _SubParsersAction tells the parser that it wants to consume everything else by passing nargs=PARSER. So we'd need some sort of nargs=PARSER_OR_NOTHING and the corresponding code everywhere that nargs is used. Perhaps there's an easier way though... Labels: Type-Enhancement −Type-Defect Dec 06, 2009 issue 46 ('-' should be a valid flag) Labels changed by steven.bethard - Could you give me a couple test cases of what you want to work? I'm a little confused by your code vs your examples. For example, 'cd -' should already work fine: >>> parser = argparse.ArgumentParser() >>> parser.add_argument('dir') >>> parser.parse_args(['-']) Namespace(dir='-') For the case where you use +/- alone as flags, do you want to use the + and - with spaces, e.g.: >>> # hypothetical >>> parser = argparse.ArgumentParser() >>> parser.add_argument('-', dest='add') >>> parser.parse_args('- X'.split()) Namespace(add='X') Or do you want to be able to squeeze the argument up against the +/- like this: >>> # hypothetical >>> parser = argparse.ArgumentParser() >>> parser.add_argument('-') >>> parser.parse_args('-X'.split()) Namespace(add='X') The former is relatively easy to support. The latter would be difficult because '-X' looks like a mis-typed flag. I guess it would be possible to just disable the mis-typed flag detection if an argument like the above is added, but I'd have to think about it more. Labels: Type-Enhancement −Type-Defect Could you give me a couple test cases of what you want to work? I'm a little confused by your code vs your examples. For example, 'cd -' should already work fine: >>> parser = argparse.ArgumentParser() >>> parser.add_argument('dir') >>> parser.parse_args(['-']) Namespace(dir='-') For the case where you use +/- alone as flags, do you want to use the + and - with spaces, e.g.: >>> # hypothetical >>> parser = argparse.ArgumentParser() >>> parser.add_argument('-', dest='add') >>> parser.parse_args('- X'.split()) Namespace(add='X') Or do you want to be able to squeeze the argument up against the +/- like this: >>> # hypothetical >>> parser = argparse.ArgumentParser() >>> parser.add_argument('-') >>> parser.parse_args('-X'.split()) Namespace(add='X') The former is relatively easy to support. The latter would be difficult because '-X' looks like a mis-typed flag. I guess it would be possible to just disable the mis-typed flag detection if an argument like the above is added, but I'd have to think about it more. Labels: Type-Enhancement −Type-Defect Dec 06, 2009 issue 45 (parse_known_args() fails when using subcommands) Status changed by steven.bethard - Yes, this is indeed an issue. The problem is that subparsers don't know whether they're being called by parse_args() or parse_known_args(). I guess the most obvious way to fix this would be to add another argument to Action.__call__ that indicates what method is being called. But that would break any existing subclasses. Another option would be to do some stack inspection using sys._getframe(). But that's not guaranteed to work on other implementations of Python. If you have any ideas how to fix this, patches are welcome. Also, if you have a more specific example of what you're trying to do, maybe I can give you a workaround. Status: Accepted Yes, this is indeed an issue. The problem is that subparsers don't know whether they're being called by parse_args() or parse_known_args(). I guess the most obvious way to fix this would be to add another argument to Action.__call__ that indicates what method is being called. But that would break any existing subclasses. Another option would be to do some stack inspection using sys._getframe(). But that's not guaranteed to work on other implementations of Python. If you have any ideas how to fix this, patches are welcome. Also, if you have a more specific example of what you're trying to do, maybe I can give you a workaround. Status: Accepted Dec 06, 2009 issue 44 (Allow conflicting argument declarations for subparsers) Labels changed by steven.bethard - What did you try that didn't work? >>> parser = argparse.ArgumentParser() >>> subparsers = parser.add_subparsers() >>> cmd1 = subparsers.add_parser('cmd1') >>> cmd1.add_argument('-v', dest='foo') >>> cmd2 = subparsers.add_parser('cmd2') >>> cmd2.add_argument('-v', dest='bar') >>> parser.parse_args(['cmd1', '-v', 'badger']) Namespace(foo='badger') >>> parser.parse_args(['cmd2', '-v', 'badger']) Namespace(bar='badger') Labels: Type-Enhancement −Type-Defect What did you try that didn't work? >>> parser = argparse.ArgumentParser() >>> subparsers = parser.add_subparsers() >>> cmd1 = subparsers.add_parser('cmd1') >>> cmd1.add_argument('-v', dest='foo') >>> cmd2 = subparsers.add_parser('cmd2') >>> cmd2.add_argument('-v', dest='bar') >>> parser.parse_args(['cmd1', '-v', 'badger']) Namespace(foo='badger') >>> parser.parse_args(['cmd2', '-v', 'badger']) Namespace(bar='badger') Labels: Type-Enhancement −Type-Defect Dec 06, 2009 r78 (Add support for nargs='...', which allows emulation of comma...) committed by steven.bethard - Add support for nargs='...', which allows emulation of command lines like "python [options] file [arguments]". Add support for nargs='...', which allows emulation of command lines like "python [options] file [arguments]". Dec 06, 2009 r77 (Add get_default method.) committed by steven.bethard - Add get_default method. Add get_default method. Dec 04, 2009 issue 48 (inconsistent --option=xxx vs --option xxx) reported by ndbecker2 - I have an option '--si' and and option '--size' (unintentional) when used with '=', ambiguous, but when used with ' ', not. python test_front_end_spec.py --order=3 -e 13.1 --sps='u(2,4)' --alpha .35 --si 64 --no-notch --size 1000000 python test_front_end_spec.py --order=3 -e 13.1 --sps='u(2,4)' --alpha .35 --si=64 --no-notch --size=1000000 usage: test_front_end_spec.py [-h] [-e ESNODB] [--alpha ALPHA] [--trials TRIALS] [--order ORDER] [-s SPS] [--size SIZE] [--si SI] [--filter [FILTER]] [--notch [NOTCH]] [-- test_front_end_spec.py: error: ambiguous option: --si=64 could match --si, --size I have an option '--si' and and option '--size' (unintentional) when used with '=', ambiguous, but when used with ' ', not. python test_front_end_spec.py --order=3 -e 13.1 --sps='u(2,4)' --alpha .35 --si 64 --no-notch --size 1000000 python test_front_end_spec.py --order=3 -e 13.1 --sps='u(2,4)' --alpha .35 --si=64 --no-notch --size=1000000 usage: test_front_end_spec.py [-h] [-e ESNODB] [--alpha ALPHA] [--trials TRIALS] [--order ORDER] [-s SPS] [--size SIZE] [--si SI] [--filter [FILTER]] [--notch [NOTCH]] [-- test_front_end_spec.py: error: ambiguous option: --si=64 could match --si, --size Nov 27, 2009 issue 47 (optional subparsers) reported by sgustafso - What steps will reproduce the problem? parser = argparse.ArgumentParser() sub = parser.add_subparsers() sub.add_parser("info") parser.add_argument("paths", "+") parser.parse_args(["foo", "bar"]) What is the expected output? What do you see instead? Expected behavior is that, failing to match one of the subparser inputs ("info"), the parser checks if the argument matches any of the top-level arguments, in this case the 'paths' multi-arg. In other words, it should be possible to make the subparser be optional, such that when the subparser argument fails to retrieve any valid subparser, the remaining args are parsed as if no subparser exists. At present, it does not seem possible to make a subparser be optional at all. Perhaps this could be exposed to the user as: parser.add_subparsers(nargs=argparse.OPTIONAL) or something to that effect. Or, allow a default subparser to be specified. I.e., sub = parser.add_subparsers() info = sub.add_parser("info") main = sub.add_parser("main") sub.default = main I'm sure the point will come up that the current behavior is correct, because given a subparser like "info", a user could easily make a mistake like "myapp ino foo bar" and rather than get a safe error be given something unexpected. For this reason, I think the default behavior is usually going to be correct. BUT, it would still be nice if it could be optional, so that developers could be free to make that call. Sometimes the potential user errors aren't really an issue, and having to explicitly set a subparse arg every time can be a nuissance. What steps will reproduce the problem? parser = argparse.ArgumentParser() sub = parser.add_subparsers() sub.add_parser("info") parser.add_argument("paths", "+") parser.parse_args(["foo", "bar"]) What is the expected output? What do you see instead? Expected behavior is that, failing to match one of the subparser inputs ("info"), the parser checks if the argument matches any of the top-level arguments, in this case the 'paths' multi-arg. In other words, it should be possible to make the subparser be optional, such that when the subparser argument fails to retrieve any valid subparser, the remaining args are parsed as if no subparser exists. At present, it does not seem possible to make a subparser be optional at all. Perhaps this could be exposed to the user as: parser.add_subparsers(nargs=argparse.OPTIONAL) or something to that effect. Or, allow a default subparser to be specified. I.e., sub = parser.add_subparsers() info = sub.add_parser("info") main = sub.add_parser("main") sub.default = main I'm sure the point will come up that the current behavior is correct, because given a subparser like "info", a user could easily make a mistake like "myapp ino foo bar" and rather than get a safe error be given something unexpected. For this reason, I think the default behavior is usually going to be correct. BUT, it would still be nice if it could be optional, so that developers could be free to make that call. Sometimes the potential user errors aren't really an issue, and having to explicitly set a subparse arg every time can be a nuissance. Nov 27, 2009 issue 46 ('-' should be a valid flag) reported by sgustafso - What steps will reproduce the problem? parser = argparser.ArgumentParser() parser.add_argument("-") parser.parser_args() What is the expected output? What do you see instead? Expect a single '-' to be a valid argument just as '+' is considered valid. Errors out with "must contain characters other than '-'" This probably seems like it should be uncommon, but a single '-' flag is something I use regularly in my command line scripts. It's so quick and easy to type that it makes for a very ideal shortcut, like 'cd -'. I also have many commands that have add/remove behavior, and in all of these cases I use +/- flags as shortcut flags to '--add' or '--remove'. Ideally, an argument parser should place no restrictions on the format of flags whatsoever. I often can't use the builtin optparse exactly because of the restrictions it places on flag names. In the way of suggestions, something that could cover this case and at the same time many other cases would be to allow flags to be regex objects. I.e., parser.add_argument(re.compile("foo")) What steps will reproduce the problem? parser = argparser.ArgumentParser() parser.add_argument("-") parser.parser_args() What is the expected output? What do you see instead? Expect a single '-' to be a valid argument just as '+' is considered valid. Errors out with "must contain characters other than '-'" This probably seems like it should be uncommon, but a single '-' flag is something I use regularly in my command line scripts. It's so quick and easy to type that it makes for a very ideal shortcut, like 'cd -'. I also have many commands that have add/remove behavior, and in all of these cases I use +/- flags as shortcut flags to '--add' or '--remove'. Ideally, an argument parser should place no restrictions on the format of flags whatsoever. I often can't use the builtin optparse exactly because of the restrictions it places on flag names. In the way of suggestions, something that could cover this case and at the same time many other cases would be to allow flags to be regex objects. I.e., parser.add_argument(re.compile("foo")) Nov 25, 2009 issue 45 (parse_known_args() fails when using subcommands) reported by whart222 - Save the attached script, and run: python test.py A --foo This generates the following output, which indicates that the unknown '--foo' option is not being ignored: usage: test A [-h] test A: error: unrecognized arguments: --foo Save the attached script, and run: python test.py A --foo This generates the following output, which indicates that the unknown '--foo' option is not being ignored: usage: test A [-h] test A: error: unrecognized arguments: --foo Nov 25, 2009 issue 44 (Allow conflicting argument declarations for subparsers) reported by whart222 - I'd like to have a command line with two subcommands, each of which has the same option. This appears to be disallowed in the current version. Example: script cmd1 -v script cmd2 -v I'd like to have a command line with two subcommands, each of which has the same option. This appears to be disallowed in the current version. Example: script cmd1 -v script cmd2 -v Earlier this year Nov 09, 2009 issue 43 (--help and --version methods; change defaults) commented on by steven.bethard - I think I wasn't clear about the tests. Changing tests to make a patch work is unacceptable. The tests should pass as they are. Changes to argparse that change the current behavior need to follow the standard processes for changing behavior in software: Release 1. Add new behavior as optional. All existing tests pass with no changes. New tests check for optional behavior. Release 2. Add deprecation warning for original behavior. All existing tests pass with no changes. New tests check for optional behavior. Release 3. Change optional behavior to default behavior. Changes to old tests are acceptable in this release. Is that clearer? So right now, a patch that requires changes to any existing tests is not an acceptable patch. Your patch must pass with no changes to the test suite, though it is fully acceptable to add tests for your new optional behavior. Changes to the test suite will not be acceptable until your new behavior has been around for at least two releases. I think I wasn't clear about the tests. Changing tests to make a patch work is unacceptable. The tests should pass as they are. Changes to argparse that change the current behavior need to follow the standard processes for changing behavior in software: Release 1. Add new behavior as optional. All existing tests pass with no changes. New tests check for optional behavior. Release 2. Add deprecation warning for original behavior. All existing tests pass with no changes. New tests check for optional behavior. Release 3. Change optional behavior to default behavior. Changes to old tests are acceptable in this release. Is that clearer? So right now, a patch that requires changes to any existing tests is not an acceptable patch. Your patch must pass with no changes to the test suite, though it is fully acceptable to add tests for your new optional behavior. Changes to the test suite will not be acceptable until your new behavior has been around for at least two releases. Nov 09, 2009 issue 43 (--help and --version methods; change defaults) commented on by bruno-th...@gmx.net - > Just to be clear, I'm not opposed to the idea of changing some defaults > - we just need to go through the standard process of making a change to > an existing library. > That means either a deprecation process (which requires community > consent) or a change which is fully backwards compatible. With the tests updated (see below), my patch does provide full backwards compatibility. >> This is not about the argparse's users community only; ... it should >> match the expectations of the whole Python community. > > I'm happy to have the poll over the whole Python community. That would > be even better. Yes of course. Many will know about (and have used) optparse and will prefer a solution which makes it easy to migrate. >> Simply removing '-v' can't possibly break any Python script using >> argparse. > > This is just not true. If someone has written a user interface with > argparse, and we make this change with no deprecation process, then > users of that interface will have their interface broken -- if they > try to use '-v' to print the version, it will no longer work. Not true when using my patch. Unless the '-v' is used in another option, it is finally used for '--version'. >> The attached patch... > > Thanks for providing a patch. I'm nervous about adding actions inside of > parse_args. > All arguments should be added before parse_args is called. Why? Is there any postprocessing done to the arguments outside the add_argument calls? Is there another hook available which would be called before parsing? What would be your suggestion how to make sure the available option strings are finally used? (you are the one who considers this crucial) > Correct me if I'm wrong, but your primary goals are to be able to > customize which > flags are used by the help and version actions, right? Wrong. I consider it important that argparse makes it as easy as possible to create scripts which follow the de-facto-standards of commandline programs; this includes -V/--version (but not -v) for the version information. It should not cause confusion by introducing an aberrant "standard" for Pythons scripts which use argparse. Currently, it is easier to create non-conforming scripts with argparse; but every aberration should need to be done on purpose (= with a particular reason, e.g. mimicking a certain program's options). > What's wrong with this: > > parser = argparse.ArgumentParser(add_help=True) > parser.add_argument('--my-help', action='help') > parser.add_argument('--my-version', action='version', version='My > Version') (add_help should the False here, of course, and the option strings differ...) > Note that if you take this approach, and you want your help argument > displayed last, > it's easy enough for you to put it there. I tell you what's wrong: it must be done explicitly, although it could be done automatically. I was always irritated when getting the least interesting options first: when calling the help, one usually is more interested in the options which are specific for the program. Consider a long help output for an important program -- so important that you want a printout. It the printout wouldn't fit on one page, you'd surely prefer the --help and --version help to be on the 2nd page, rather than some more important option. My patch simply kills three birds with one stone: * it makes -v and -h available for e.g. --verbose and --host uses * it retains them for --version and --help, if not used otherwise * it moves the least interesting options to the end Of course it would be possible (and better than nothing) to finally /insert/ the postponed arguments; but this would seem to me like putting on the pants with pliers. > I guess I should also say that any patch that breaks existing tests > (yes, including those that test exact help output) is not an > acceptable patch. (...) Of course I didn't expect you to commit the patch immediately; but you could have tried it and see that it works nicely. As I already wrote ("I could try to tackle this problem with vim and a few regular expression substitutions."), I'm working on the tests issue. I managed to move the lines using regular expressions, but still got many errors, and the differences aren't easy to spot. In the Roundup issue-tracker project, we have nice diffs; my next patch will enable these for test_argparse, too. When providing a tests patch, I'll add a commented sed script which creates it; this will help you in reviewing the changes. > Just to be clear, I'm not opposed to the idea of changing some defaults > - we just need to go through the standard process of making a change to > an existing library. > That means either a deprecation process (which requires community > consent) or a change which is fully backwards compatible. With the tests updated (see below), my patch does provide full backwards compatibility. >> This is not about the argparse's users community only; ... it should >> match the expectations of the whole Python community. > > I'm happy to have the poll over the whole Python community. That would > be even better. Yes of course. Many will know about (and have used) optparse and will prefer a solution which makes it easy to migrate. >> Simply removing '-v' can't possibly break any Python script using >> argparse. > > This is just not true. If someone has written a user interface with > argparse, and we make this change with no deprecation process, then > users of that interface will have their interface broken -- if they > try to use '-v' to print the version, it will no longer work. Not true when using my patch. Unless the '-v' is used in another option, it is finally used for '--version'. >> The attached patch... > > Thanks for providing a patch. I'm nervous about adding actions inside of > parse_args. > All arguments should be added before parse_args is called. Why? Is there any postprocessing done to the arguments outside the add_argument calls? Is there another hook available which would be called before parsing? What would be your suggestion how to make sure the available option strings are finally used? (you are the one who considers this crucial) > Correct me if I'm wrong, but your primary goals are to be able to > customize which > flags are used by the help and version actions, right? Wrong. I consider it important that argparse makes it as easy as possible to create scripts which follow the de-facto-standards of commandline programs; this includes -V/--version (but not -v) for the version information. It should not cause confusion by introducing an aberrant "standard" for Pythons scripts which use argparse. Currently, it is easier to create non-conforming scripts with argparse; but every aberration should need to be done on purpose (= with a particular reason, e.g. mimicking a certain program's options). > What's wrong with this: > > parser = argparse.ArgumentParser(add_help=True) > parser.add_argument('--my-help', action='help') > parser.add_argument('--my-version', action='version', version='My > Version') (add_help should the False here, of course, and the option strings differ...) > Note that if you take this approach, and you want your help argument > displayed last, > it's easy enough for you to put it there. I tell you what's wrong: it must be done explicitly, although it could be done automatically. I was always irritated when getting the least interesting options first: when calling the help, one usually is more interested in the options which are specific for the program. Consider a long help output for an important program -- so important that you want a printout. It the printout wouldn't fit on one page, you'd surely prefer the --help and --version help to be on the 2nd page, rather than some more important option. My patch simply kills three birds with one stone: * it makes -v and -h available for e.g. --verbose and --host uses * it retains them for --version and --help, if not used otherwise * it moves the least interesting options to the end Of course it would be possible (and better than nothing) to finally /insert/ the postponed arguments; but this would seem to me like putting on the pants with pliers. > I guess I should also say that any patch that breaks existing tests > (yes, including those that test exact help output) is not an > acceptable patch. (...) Of course I didn't expect you to commit the patch immediately; but you could have tried it and see that it works nicely. As I already wrote ("I could try to tackle this problem with vim and a few regular expression substitutions."), I'm working on the tests issue. I managed to move the lines using regular expressions, but still got many errors, and the differences aren't easy to spot. In the Roundup issue-tracker project, we have nice diffs; my next patch will enable these for test_argparse, too. When providing a tests patch, I'll add a commented sed script which creates it; this will help you in reviewing the changes. Nov 07, 2009 r76 (Fix setup.py bugs caught by Yuvgoog.) committed by steven.bethard - Fix setup.py bugs caught by Yuvgoog. Fix setup.py bugs caught by Yuvgoog. Nov 07, 2009 issue 43 (--help and --version methods; change defaults) commented on by steven.bethard - I guess I should also say that any patch that breaks existing tests (yes, including those that test exact help output) is not an acceptable patch. Changes that break tests are backwards incompatible changes, and they need to be added following the usual deprecation process, which means that for the current version, no tests should fail. I guess I should also say that any patch that breaks existing tests (yes, including those that test exact help output) is not an acceptable patch. Changes that break tests are backwards incompatible changes, and they need to be added following the usual deprecation process, which means that for the current version, no tests should fail. Nov 07, 2009 issue 43 (--help and --version methods; change defaults) commented on by steven.bethard - Just to be clear, I'm not opposed to the idea of changing some defaults - we just need to go through the standard process of making a change to an existing library. That means either a deprecation process (which requires community consent) or a change which is fully backwards compatible. > This is not about the argparse's users community only; ... it should match the > expectations of the whole Python community. I'm happy to have the poll over the whole Python community. That would be even better. > Simply removing '-v' can't possibly break any Python script using argparse. This is just not true. If someone has written a user interface with argparse, and we make this change with no deprecation process, then users of that interface will have their interface broken -- if they try to use '-v' to print the version, it will no longer work. > The attached patch... Thanks for providing a patch. I'm nervous about adding actions inside of parse_args. All arguments should be added before parse_args is called. Correct me if I'm wrong, but your primary goals are to be able to customize which flags are used by the help and version actions, right? What's wrong with this: parser = argparse.ArgumentParser(add_help=True) parser.add_argument('--my-help', action='help') parser.add_argument('--my-version', action='version', version='My Version') Note that if you take this approach, and you want your help argument displayed last, it's easy enough for you to put it there. Just to be clear, I'm not opposed to the idea of changing some defaults - we just need to go through the standard process of making a change to an existing library. That means either a deprecation process (which requires community consent) or a change which is fully backwards compatible. > This is not about the argparse's users community only; ... it should match the > expectations of the whole Python community. I'm happy to have the poll over the whole Python community. That would be even better. > Simply removing '-v' can't possibly break any Python script using argparse. This is just not true. If someone has written a user interface with argparse, and we make this change with no deprecation process, then users of that interface will have their interface broken -- if they try to use '-v' to print the version, it will no longer work. > The attached patch... Thanks for providing a patch. I'm nervous about adding actions inside of parse_args. All arguments should be added before parse_args is called. Correct me if I'm wrong, but your primary goals are to be able to customize which flags are used by the help and version actions, right? What's wrong with this: parser = argparse.ArgumentParser(add_help=True) parser.add_argument('--my-help', action='help') parser.add_argument('--my-version', action='version', version='My Version') Note that if you take this approach, and you want your help argument displayed last, it's easy enough for you to put it there. Nov 07, 2009 issue 43 (--help and --version methods; change defaults) commented on by bruno-th...@gmx.net - This is not about the argparse's users community only; you want argpase to be a standard module, and as such it should match the expectations of the whole Python community. Let's face the fact that the "-v" --version switch is not common anywhere else, and an argument parsing library shouldn't invent new standards here but support people in writing programs which behave like they are commonly expected to behave. optparse uses '--version' only; adding '-v' to the list makes it harder to replace optparse by argparse. Simply removing '-v' can't possibly break any Python script using argparse. Replacing it by '-V' would IMHO be unlikely to do so; however, since you are so concerned about it: the attached patch keeps the '-v' string; it will be available unless the '-v' is used in another option. The attached patch - moves the creation of the version and help options to their own public methods add_help_argument and add_version_argument (could be named add_help_option etc. as well, since these are options) - postpones the creation of these options. This way, the really interesting options are printed first, just below the usage info (and, if present, the required arguments); the --help option is printed last, where it is spotted easily. - introduces the new conflict_handler 'modest' which drops option strings for the new (postponed) action but raises an ArgumentError when none are left (which will happen only when someone has used e.g. the '--version' string for some other option) This way, all existing scripts will continue to work; everyone can use -v, -V and -h to his heart's content; and the --version and --help options are moved to the bottom. I noticed that many tests fail now because they check the exact help output; I could try to tackle this problem with vim and a few regular expression substitutions. This is not about the argparse's users community only; you want argpase to be a standard module, and as such it should match the expectations of the whole Python community. Let's face the fact that the "-v" --version switch is not common anywhere else, and an argument parsing library shouldn't invent new standards here but support people in writing programs which behave like they are commonly expected to behave. optparse uses '--version' only; adding '-v' to the list makes it harder to replace optparse by argparse. Simply removing '-v' can't possibly break any Python script using argparse. Replacing it by '-V' would IMHO be unlikely to do so; however, since you are so concerned about it: the attached patch keeps the '-v' string; it will be available unless the '-v' is used in another option. The attached patch - moves the creation of the version and help options to their own public methods add_help_argument and add_version_argument (could be named add_help_option etc. as well, since these are options) - postpones the creation of these options. This way, the really interesting options are printed first, just below the usage info (and, if present, the required arguments); the --help option is printed last, where it is spotted easily. - introduces the new conflict_handler 'modest' which drops option strings for the new (postponed) action but raises an ArgumentError when none are left (which will happen only when someone has used e.g. the '--version' string for some other option) This way, all existing scripts will continue to work; everyone can use -v, -V and -h to his heart's content; and the --version and --help options are moved to the bottom. I noticed that many tests fail now because they check the exact help output; I could try to tackle this problem with vim and a few regular expression substitutions. Nov 06, 2009 issue 43 (--help and --version methods; change defaults) commented on by steven.bethard - There are two things missing from your proposal that would be crucial for changing the "-h" and "-v" defaults: (1) Evidence from the community of argparse users that the "-h" and "-v" defaults are inappropriate for most people. (2) A clear deprecation and upgrade strategy for people who are relying on the current behavior and will need to move to your new suggested behavior. I'm open to changing things if you can provide both of these items. There are two things missing from your proposal that would be crucial for changing the "-h" and "-v" defaults: (1) Evidence from the community of argparse users that the "-h" and "-v" defaults are inappropriate for most people. (2) A clear deprecation and upgrade strategy for people who are relying on the current behavior and will need to move to your new suggested behavior. I'm open to changing things if you can provide both of these items. Nov 06, 2009 issue 43 (--help and --version methods; change defaults) commented on by bruno-th...@gmx.net - Just found issue 22 (I have seeked before, but I finally found it when viewing all issues, omitting any search expressions). I don't like the solution because "version='%(prog)s 2.0'" should not be an attribute of the argument but of the ArgumentParser; and it is a keyword argument for one special case only, where a suitable argument is already present for the constructor. And '-v' is a bad (and unnecessary!) choice for the --version option, like stated before. If it would be removed (or replaced by '-V'), everyone could have a --version argument without blocking -v, just by specifying the version. Just found issue 22 (I have seeked before, but I finally found it when viewing all issues, omitting any search expressions). I don't like the solution because "version='%(prog)s 2.0'" should not be an attribute of the argument but of the ArgumentParser; and it is a keyword argument for one special case only, where a suitable argument is already present for the constructor. And '-v' is a bad (and unnecessary!) choice for the --version option, like stated before. If it would be removed (or replaced by '-V'), everyone could have a --version argument without blocking -v, just by specifying the version. Nov 06, 2009 issue 43 (--help and --version methods; change defaults) reported by bruno-th...@gmx.net - What steps will reproduce the problem? >>> import argparse >>> parser = argparse.ArgumentParser(version='0.1') >>> parser.add_argument('--verbose', '-v', action='store_true') >>> (I have used optparse for quite a while and use -v/--verbose all the time) What is the expected output? What do you see instead? I expect: _StoreTrueAction(option_strings=['--verbose', '-v'], dest='verbose', nargs=0, const=True, default=False, type=None, choices=None, help=None, metavar=None) I get: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "argparse.py", line 1287, in add_argument return self._add_action(action) File "argparse.py", line 1659, in _add_action self._optionals._add_action(action) File "argparse.py", line 1496, in _add_action action = super(_ArgumentGroup, self)._add_action(action) File "argparse.py", line 1301, in _add_action self._check_conflict(action) File "argparse.py", line 1448, in _check_conflict conflict_handler(action, confl_optionals) File "argparse.py", line 1455, in _handle_conflict_error raise ArgumentError(action, message % conflict_string) argparse.ArgumentError: argument -v/--version: conflicting option string(s): -v What version of the product are you using? On what operating system? 1.1a1 (os independent) As of argparse 1.1a1, the --help (unless suppressed) and --version arguments are created during initialization of the ArgumentParser by calls to the all-purpose method add_argument (directly in the __init__ method). This way it is not easily possible to override the default arguments in a subclass of ArgumentParser; help and version info creation must be suppressed and done explicitly. This is inconvenient. "-v" is not commonly used as a --version shorthand: cp: --version (-v is --verbose) find: --version (no -v or -V argument) grep: -V, --version less: -V, --version (no -v argument) ls: --version (no -v argument) sed: -V, --version wc: --version (no -v argument) InfoZip's zip uses -v for verbose operation and version info, but this is not a serious option... Some programs even use -h for something else than the help: e.g. for the (quite important) host argument of database commandline clients, and grep uses -h/-H for the enforcement/suppression of filenames. cp: --help dirname: --help find: --help (no -h or -? argument) grep: --help less: --help, -? ("Number is required after -h") ls: --help (no -h or -? argument) sed: --help, -h, -? unzip: --help, -h, -? zip: --help, -h, -? As long as the default help and version arguments are created first and block usage of -h and -v for other options, IMO the default option strings must be reduced to: --help (always help, if present) -? (dto.) --version (the only version option which is always implemented) If the creation of these options would be delayed (just before parsing), -h, -V and perhaps -v could be tried as well, but this is another proposal. For now, I propose to - change the default option strings (blocking -v is a defect IMO) - put the calls to add_argument in dedicated methods -- e.g. add_help_argument, add_version_argument -- which can be easily overridden or monkey-patched. What steps will reproduce the problem? >>> import argparse >>> parser = argparse.ArgumentParser(version='0.1') >>> parser.add_argument('--verbose', '-v', action='store_true') >>> (I have used optparse for quite a while and use -v/--verbose all the time) What is the expected output? What do you see instead? I expect: _StoreTrueAction(option_strings=['--verbose', '-v'], dest='verbose', nargs=0, const=True, default=False, type=None, choices=None, help=None, metavar=None) I get: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "argparse.py", line 1287, in add_argument return self._add_action(action) File "argparse.py", line 1659, in _add_action self._optionals._add_action(action) File "argparse.py", line 1496, in _add_action action = super(_ArgumentGroup, self)._add_action(action) File "argparse.py", line 1301, in _add_action self._check_conflict(action) File "argparse.py", line 1448, in _check_conflict conflict_handler(action, confl_optionals) File "argparse.py", line 1455, in _handle_conflict_error raise ArgumentError(action, message % conflict_string) argparse.ArgumentError: argument -v/--version: conflicting option string(s): -v What version of the product are you using? On what operating system? 1.1a1 (os independent) As of argparse 1.1a1, the --help (unless suppressed) and --version arguments are created during initialization of the ArgumentParser by calls to the all-purpose method add_argument (directly in the __init__ method). This way it is not easily possible to override the default arguments in a subclass of ArgumentParser; help and version info creation must be suppressed and done explicitly. This is inconvenient. "-v" is not commonly used as a --version shorthand: cp: --version (-v is --verbose) find: --version (no -v or -V argument) grep: -V, --version less: -V, --version (no -v argument) ls: --version (no -v argument) sed: -V, --version wc: --version (no -v argument) InfoZip's zip uses -v for verbose operation and version info, but this is not a serious option... Some programs even use -h for something else than the help: e.g. for the (quite important) host argument of database commandline clients, and grep uses -h/-H for the enforcement/suppression of filenames. cp: --help dirname: --help find: --help (no -h or -? argument) grep: --help less: --help, -? ("Number is required after -h") ls: --help (no -h or -? argument) sed: --help, -h, -? unzip: --help, -h, -? zip: --help, -h, -? As long as the default help and version arguments are created first and block usage of -h and -v for other options, IMO the default option strings must be reduced to: --help (always help, if present) -? (dto.) --version (the only version option which is always implemented) If the creation of these options would be delayed (just before parsing), -h, -V and perhaps -v could be tried as well, but this is another proposal. For now, I propose to - change the default option strings (blocking -v is a defect IMO) - put the calls to add_argument in dedicated methods -- e.g. add_help_argument, add_version_argument -- which can be easily overridden or monkey-patched. Nov 02, 2009 r75 (Python 2.3 compatibility: re.findall doesn't accept flags in...) committed by ubershmekel - Python 2.3 compatibility: re.findall doesn't accept flags in 2.3. Python 2.3 compatibility: re.findall doesn't accept flags in 2.3. Nov 02, 2009 r74 (argparse.run now works with bound methods (instance methods ...) committed by ubershmekel - argparse.run now works with bound methods (instance methods and class methods). argparse.run now works with bound methods (instance methods and class methods). Nov 02, 2009 r73 (Allow alphanumeric version number (\w and not \d).) committed by ubershmekel - Allow alphanumeric version number (\w and not \d). Allow alphanumeric version number (\w and not \d). Nov 02, 2009 issue 20 (optionals with nargs='+' can't be followed by positionals) commented on by steven.bethard - Issue 42 has been merged into this issue. Issue 42 has been merged into this issue. Nov 02, 2009 issue 42 (values to arguments should be mandatred to be placed immedia...) changed by steven.bethard - Status: Duplicate Status: Duplicate Nov 01, 2009 issue 42 (values to arguments should be mandatred to be placed immedia...) commented on by r...@researchut.com - Ah!! Looks like Steve is already aware of the problem (Defect #20) Ah!! Looks like Steve is already aware of the problem (Defect #20) Nov 01, 2009 issue 42 (values to arguments should be mandatred to be placed immedia...) reported by r...@researchut.com - What steps will reproduce the problem? Consider this example: # SET command options # parser_set = subparsers.add_parser('set', parents=[global_options]) parser_set.set_defaults(func=setter) parser_set.add_argument('set', help="Generate a signature file", action="store", type=str, metavar="apt-offline.sig", default="apt-offline.sig") #TODO: Handle nargs here. parser_set.add_argument("--install-packages", dest="set_install_packages", help="Packages that need to be installed", action="store", type=str, nargs='', metavar="PKG") parser_set.add_argument("--install-src-packages", dest="set_install_src_packages", help="Source Packages that need to be installed", action="store", type=str, nargs='', metavar="SOURCE PKG") "set" here is a command/argument which expects a value, in this case a file. Set also has many options. Like the above ones with nargs=''. Since argparse is not mandating the placement of the value for the "set" argument, it fails if that value is places after the option/argument of type nargs='' rrs@champaran:~/devel/apt-offline/apt-offline (master)$ apt-offline set --install-packages foo bar /tmp/foo.uris usage: apt-offline set [-h] [--verbose] [--test-windows] [--install-packages [PKG [PKG ...]]] [--install-src-packages [SOURCE PKG [SOURCE PKG ...]]] [--src-build-dep] [--release release_name] [--update] [--upgrade] [--upgrade-type upgrade] apt-offline.sig apt-offline set: error: too few arguments rrs@champaran:~/devel/apt-offline/apt-offline (master)$ less AptOfflineCoreLib.py rrs@champaran:~/devel/apt-offline/apt-offline (master)$ sudo apt-offline set /tmp/foo.uris --install-packages foo bar [sudo] password for rrs: Generating database of package foo, bar, and its dependencies. What is the expected output? What do you see instead? Placements should either be mandated or else argparse should be able to handle the case I've mentioned above. What version of the product are you using? On what operating system? argparse 1.0.1 Linux What steps will reproduce the problem? Consider this example: # SET command options # parser_set = subparsers.add_parser('set', parents=[global_options]) parser_set.set_defaults(func=setter) parser_set.add_argument('set', help="Generate a signature file", action="store", type=str, metavar="apt-offline.sig", default="apt-offline.sig") #TODO: Handle nargs here. parser_set.add_argument("--install-packages", dest="set_install_packages", help="Packages that need to be installed", action="store", type=str, nargs='', metavar="PKG") parser_set.add_argument("--install-src-packages", dest="set_install_src_packages", help="Source Packages that need to be installed", action="store", type=str, nargs='', metavar="SOURCE PKG") "set" here is a command/argument which expects a value, in this case a file. Set also has many options. Like the above ones with nargs=''. Since argparse is not mandating the placement of the value for the "set" argument, it fails if that value is places after the option/argument of type nargs='' rrs@champaran:~/devel/apt-offline/apt-offline (master)$ apt-offline set --install-packages foo bar /tmp/foo.uris usage: apt-offline set [-h] [--verbose] [--test-windows] [--install-packages [PKG [PKG ...]]] [--install-src-packages [SOURCE PKG [SOURCE PKG ...]]] [--src-build-dep] [--release release_name] [--update] [--upgrade] [--upgrade-type upgrade] apt-offline.sig apt-offline set: error: too few arguments rrs@champaran:~/devel/apt-offline/apt-offline (master)$ less AptOfflineCoreLib.py rrs@champaran:~/devel/apt-offline/apt-offline (master)$ sudo apt-offline set /tmp/foo.uris --install-packages foo bar [sudo] password for rrs: Generating database of package foo, bar, and its dependencies. What is the expected output? What do you see instead? Placements should either be mandated or else argparse should be able to handle the case I've mentioned above. What version of the product are you using? On what operating system? argparse 1.0.1 Linux Oct 31, 2009 issue 41 (Documentation section 3.1.5 seems to include text for 3.1.4) Status changed by steven.bethard - Thanks for the bug report. This should now be fixed in v1.1a1 as of r72. Status: Fixed Thanks for the bug report. This should now be fixed in v1.1a1 as of r72. Status: Fixed Oct 31, 2009 r72 (Fix misplaced discussion of add_help and parent parsers.) committed by steven.bethard - Fix misplaced discussion of add_help and parent parsers. Fix misplaced discussion of add_help and parent parsers. Oct 29, 2009 issue 40 (%(prog)s in version string is not being replaced) Status changed by steven.bethard - I need to actually make a release with the trunk version, and then I'll upload new packages. I'm not sure how soon I'll be making a release though. I'll try to do one in the next month or two. Status: Fixed I need to actually make a release with the trunk version, and then I'll upload new packages. I'm not sure how soon I'll be making a release though. I'll try to do one in the next month or two. Status: Fixed Oct 29, 2009 issue 41 (Documentation section 3.1.5 seems to include text for 3.1.4) commented on by jdclark66 - This appears to still be an issue in the argparse v1.1a1 documentation that is downloaded as part of the trunk. This appears to still be an issue in the argparse v1.1a1 documentation that is downloaded as part of the trunk. Oct 29, 2009 issue 40 (%(prog)s in version string is not being replaced) commented on by jdclark66 - It does appear that this is no longer a problem in the trunk version. Are there plans to update the installation packages with the latest trunk version? It does appear that this is no longer a problem in the trunk version. Are there plans to update the installation packages with the latest trunk version? Oct 29, 2009 issue 40 (%(prog)s in version string is not being replaced) commented on by steven.bethard - Yeah, I caught this bug in r68. Could you confirm its gone in trunk? Yeah, I caught this bug in r68. Could you confirm its gone in trunk? Oct 29, 2009 issue 41 (Documentation section 3.1.5 seems to include text for 3.1.4) reported by jdclark66 - Section 3.1.5 in the 1.0.1 argparse documentation file describes the prefix_chars parameter for the ArgumentParser init call. However, the last two lines of this section appear to be dscussing the proper use of the add_help parameter which was discussed in 3.1.4. What is the expected output? What do you see instead? see above What version of the product are you using? On what operating system? Version 1.0.1 of the argparse documentation Please provide any additional information below. Section 3.1.5 in the 1.0.1 argparse documentation file describes the prefix_chars parameter for the ArgumentParser init call. However, the last two lines of this section appear to be dscussing the proper use of the add_help parameter which was discussed in 3.1.4. What is the expected output? What do you see instead? see above What version of the product are you using? On what operating system? Version 1.0.1 of the argparse documentation Please provide any additional information below. Oct 29, 2009 issue 40 (%(prog)s in version string is not being replaced) reported by jdclark66 - What steps will reproduce the problem? >>> import argparse >>> parser = argparse.ArgumentParser(prog='PROG', version='%(prog)s 3.5') >>> parser.parse_args(['-v']) %(prog)s 3.5 What is the expected output? What do you see instead? I expect to see "PROG 3.5", and what I see is "%(prog)s 3.5" (without the quotes). What version of the product are you using? On what operating system? Using version 1.0.1 on Active Python 2.6.2.2 on Windows Vista. Problem also seems to happen using Jython 2.5.1 on Windows Vista. Please provide any additional information below. What steps will reproduce the problem? >>> import argparse >>> parser = argparse.ArgumentParser(prog='PROG', version='%(prog)s 3.5') >>> parser.parse_args(['-v']) %(prog)s 3.5 What is the expected output? What do you see instead? I expect to see "PROG 3.5", and what I see is "%(prog)s 3.5" (without the quotes). What version of the product are you using? On what operating system? Using version 1.0.1 on Active Python 2.6.2.2 on Windows Vista. Problem also seems to happen using Jython 2.5.1 on Windows Vista. Please provide any additional information below. Oct 24, 2009 issue 29 (Feature Request: Declarative interface using a decorator) commented on by steven.bethard - Yuvgoog Greenle's branch is now available, and it does some of this. Please join the conversation about it here: http://groups.google.com/group/argparse-users/browse_thread/thread/3ae8dd528324219f Yuvgoog Greenle's branch is now available, and it does some of this. Please join the conversation about it here: http://groups.google.com/group/argparse-users/browse_thread/thread/3ae8dd528324219f Oct 24, 2009 r71 (Add modified version of Yuvgoog Greenle's initial patch.) committed by steven.bethard - Add modified version of Yuvgoog Greenle's initial patch. Add modified version of Yuvgoog Greenle's initial patch. Oct 24, 2009 r70 (Create branch for function introspection and decorator work.) committed by steven.bethard - Create branch for function introspection and decorator work. Create branch for function introspection and decorator work.

issue 43 (--help and --version methods; change defaults) commented on by bruno-th...@gmx.net - > Just to be clear, I'm not opposed to the idea of changing some defaults > - we just need to go through the standard process of making a change to > an existing library. > That means either a deprecation process (which requires community > consent) or a change which is fully backwards compatible. With the tests updated (see below), my patch *does* provide full backwards compatibility. >> This is not about the argparse's users community only; ... it should >> match the expectations of the whole Python community. > > I'm happy to have the poll over the whole Python community. That would > be even better. Yes of course. Many will know about (and have used) optparse and will prefer a solution which makes it easy to migrate. >> Simply removing '-v' can't possibly break any Python script using >> argparse. > > This is just not true. If someone has written a user interface with > argparse, and we make this change with no deprecation process, then > users of that interface will have their interface broken -- if they > try to use '-v' to print the version, it will no longer work. Not true when using my patch. Unless the '-v' is used in another option, it is finally used for '--version'. >> The attached patch... > > Thanks for providing a patch. I'm nervous about adding actions inside of > parse_args. > All arguments should be added before parse_args is called. Why? Is there any postprocessing done to the arguments outside the add_argument calls? Is there another hook available which would be called before parsing? What would be *your* suggestion how to make sure the available option strings are finally used? (you are the one who considers this crucial) > Correct me if I'm wrong, but your primary goals are to be able to > customize which > flags are used by the help and version actions, right? Wrong. I consider it important that argparse makes it as easy as possible to create scripts which follow the de-facto-standards of commandline programs; this includes -V/--version (but *not* -v) for the version information. It should not cause confusion by introducing an aberrant "standard" for Pythons scripts which use argparse. Currently, it is easier to create non-conforming scripts with argparse; but every aberration should need to be done on purpose (= with a particular reason, e.g. mimicking a certain program's options). > What's wrong with this: > > parser = argparse.ArgumentParser(add_help=True) > parser.add_argument('--my-help', action='help') > parser.add_argument('--my-version', action='version', version='My > Version') (add_help should the False here, of course, and the option strings differ...) > Note that if you take this approach, and you want your help argument > displayed last, > it's easy enough for you to put it there. I tell you what's wrong: it must be done explicitly, although it could be done automatically. I was always irritated when getting the least interesting options first: when calling the help, one usually is more interested in the options which are specific for the program. Consider a long help output for an important program -- so important that you want a printout. It the printout wouldn't fit on one page, you'd surely prefer the --help and --version help to be on the 2nd page, rather than some more important option. My patch simply kills three birds with one stone: * it makes -v and -h available for e.g. --verbose and --host uses * it retains them for --version and --help, if not used otherwise * it moves the least interesting options to the end Of course it would be possible (and better than nothing) to finally /insert/ the postponed arguments; but this would seem to me like putting on the pants with pliers. > I guess I should also say that any patch that breaks existing tests > (yes, including those that test exact help output) is not an > acceptable patch. (...) *Of course* I didn't expect you to commit the patch immediately; but you could have tried it and see that it works nicely. As I already wrote ("I could try to tackle this problem with vim and a few regular expression substitutions."), I'm working on the tests issue. I managed to move the lines using regular expressions, but still got many errors, and the differences aren't easy to spot. In the Roundup issue-tracker project, we have nice diffs; my next patch will enable these for test_argparse, too. When providing a tests patch, I'll add a commented sed script which creates it; this will help you in reviewing the changes.

> Just to be clear, I'm not opposed to the idea of changing some defaults > - we just need to go through the standard process of making a change to > an existing library. > That means either a deprecation process (which requires community > consent) or a change which is fully backwards compatible. With the tests updated (see below), my patch *does* provide full backwards compatibility. >> This is not about the argparse's users community only; ... it should >> match the expectations of the whole Python community. > > I'm happy to have the poll over the whole Python community. That would > be even better. Yes of course. Many will know about (and have used) optparse and will prefer a solution which makes it easy to migrate. >> Simply removing '-v' can't possibly break any Python script using >> argparse. > > This is just not true. If someone has written a user interface with > argparse, and we make this change with no deprecation process, then > users of that interface will have their interface broken -- if they > try to use '-v' to print the version, it will no longer work. Not true when using my patch. Unless the '-v' is used in another option, it is finally used for '--version'. >> The attached patch... > > Thanks for providing a patch. I'm nervous about adding actions inside of > parse_args. > All arguments should be added before parse_args is called. Why? Is there any postprocessing done to the arguments outside the add_argument calls? Is there another hook available which would be called before parsing? What would be *your* suggestion how to make sure the available option strings are finally used? (you are the one who considers this crucial) > Correct me if I'm wrong, but your primary goals are to be able to > customize which > flags are used by the help and version actions, right? Wrong. I consider it important that argparse makes it as easy as possible to create scripts which follow the de-facto-standards of commandline programs; this includes -V/--version (but *not* -v) for the version information. It should not cause confusion by introducing an aberrant "standard" for Pythons scripts which use argparse. Currently, it is easier to create non-conforming scripts with argparse; but every aberration should need to be done on purpose (= with a particular reason, e.g. mimicking a certain program's options). > What's wrong with this: > > parser = argparse.ArgumentParser(add_help=True) > parser.add_argument('--my-help', action='help') > parser.add_argument('--my-version', action='version', version='My > Version') (add_help should the False here, of course, and the option strings differ...) > Note that if you take this approach, and you want your help argument > displayed last, > it's easy enough for you to put it there. I tell you what's wrong: it must be done explicitly, although it could be done automatically. I was always irritated when getting the least interesting options first: when calling the help, one usually is more interested in the options which are specific for the program. Consider a long help output for an important program -- so important that you want a printout. It the printout wouldn't fit on one page, you'd surely prefer the --help and --version help to be on the 2nd page, rather than some more important option. My patch simply kills three birds with one stone: * it makes -v and -h available for e.g. --verbose and --host uses * it retains them for --version and --help, if not used otherwise * it moves the least interesting options to the end Of course it would be possible (and better than nothing) to finally /insert/ the postponed arguments; but this would seem to me like putting on the pants with pliers. > I guess I should also say that any patch that breaks existing tests > (yes, including those that test exact help output) is not an > acceptable patch. (...) *Of course* I didn't expect you to commit the patch immediately; but you could have tried it and see that it works nicely. As I already wrote ("I could try to tackle this problem with vim and a few regular expression substitutions."), I'm working on the tests issue. I managed to move the lines using regular expressions, but still got many errors, and the differences aren't easy to spot. In the Roundup issue-tracker project, we have nice diffs; my next patch will enable these for test_argparse, too. When providing a tests patch, I'll add a commented sed script which creates it; this will help you in reviewing the changes.

Last 7 days

Last 30 days

Earlier this year