clagraff / argparse Goto Github PK

Inspired by: https://docs.python.org/dev/library/argparse.html#conflict-handler

If two options are added to the parser which share the same name, how should the conflict be handled? Currently, they will override each other such that the last option added is the option that will exist.

Is this ideal? Python allows for the option to attempt to "resolve" such conflicts. Personally, I don't think I want to support this.
I could potentially see either keeping with how the library currently overrides duplicated options; or, panic when a duplicated option name is used.

Adding nested parsers to represent program commands would be a good feature to include.

I'm very happy with this argparse package! Thank you for your excellent work.

I just found one very tiny issue:

I want to specify a command-line option that can take 4 values: "-r", "-R", "--recurse", and "--recursive". I know that I can do so as follows:

recursiveFlag := argparse.NewFlag("r R recurse recursive", "recursive", "Run recursively").Default("false")

This works perfectly when I run the program: all possibilities for the option are indeed accepted. However, if the "help" text is printed, the following shows up in the "optional arguments:" section ...

-r, -r, --recurse, --recursive Run recursively

In other words, the "-R" option is translated to lower case in this "help" text.

Again, I know that the command-line parser itself handles this correctly, because if I leave "R" out of the NewFlag() function call, then "-R" is no longer accepted by the command-line parser.

This is nothing more than a small issue with the rendering of the "help" text.

I would suggest switching the Namespace struct from:

type Namespace struct {
	Mapping map[string]interface{}
}

to the more simple structure of:

type Namespace map[string]interface{}

as there is no real usage for having an extra layer between the user and the parsed data.

As per argparse in Python, if we had a program prog.py with a help flag an a required positional argument named echo, the usage should look like:

usage: prog.py [-h] echo

But currently the package would output like:
usage: main [-h] [e ECHO]

The main difference I am trying to highlight is that there are no square brackets in the Python usage statement for echo but there are brackets surrounding the echo argument in the package's version.

As per: https://docs.python.org/dev/library/argparse.html#prefix-chars

When parsing a slice of provided string arguments, the parser should have the option to of specifying what preceeding characters are used to indicate the following text is the short/long name for an option.

For example:

...
parser.PrefixChars("+", "#")
...

which allows us to prefix our arguments with those characters:

> go run main.go +f
> go run main.go ++foo
> go run main.go #b
> go run main.go ##bar
... etc

If the - character is not included in the PrefixChars arguments, then it is not an acceptable option-prefix.

As per: https://docs.python.org/dev/library/argparse.html#epilog

Add an epilog method which will be used to store text to be outputted after the help-text of a parser.

It would be nice to be able to scan a parsers args into a struct.

Cannot set an Option to use the Append or AppendConst action because when the Namespace for the parser is initialized, it will use a string type for the value, instead of a []string as would be required for the Append-actions to work.

Non-positional options which have both a long and short name will not be found and utilized correctly, as the parser only checked the current option name against the entire DisplayName() result for all stored options.

Instead, it should check for all the possibilities within the display name against the current option name.

The README.md is now out of date. In addition, it is lacking much information on some of the specific details covering options, actions, and parser instances.

This all should be updated.

I am leaving this as an issue to be considered later.
See: https://docs.python.org/dev/library/argparse.html#allow-abbrev

Python3's argparse (by default) supports using abbreviations of options. So, for instance,

python some_cli.py --f
python some_cli.py --foo
python some_cli.py --foobar

are all acceptable values for the --foobar long-named option.

I am not convinced I actually want to support that. I can understand the benefit of not having to type out a very long option name. But at the same time, not supporting this feature could help inspire avoid such long names...

Gonna think about this one.

Derived from: https://docs.python.org/dev/library/argparse.html#fromfile-prefix-chars

Do we want to allow for using a certain prefix-character(s) to indicate that a file being specified needs to be read, and have each line added as individual arguments to the parser, in place of the original argument.

Here is the python example:

>>> with open('args.txt', 'w') as fp:
...     fp.write('-f\nbar')
>>> parser = argparse.ArgumentParser(fromfile_prefix_chars='@')
>>> parser.add_argument('-f')
>>> parser.parse_args(['-f', 'foo', '@args.txt'])
Namespace(f='bar')

So, the library could do something similar:

parser.FromFilePrefix("@")

Which would expand the file, line by line, to individual arguments.
Is this worth implementing? I have never heard of anyone using this in practice.

When setting a default value for an Option/Flag, it should be possible to support defaulting to a value as specified in an environmental variable.

For example:

fooFlag := argparse.NewFlag("f foo", "foo", "Set foo").Default("$FOO_ENV")

It could parse for the regex pattern (^\$[A-Z_]+[0-9A-Z_]*)$ for all enviromental variable names, and then use the corresponding value (if exists) as the default.

See regexr for examples.

Is there a way like this?

def project_stat(args):
    pass

def delete_one_project_from_databse(args):
    pass

def main():
    parser=argparse.ArgumentParser(description='',
        formatter_class=argparse.RawDescriptionHelpFormatter)
    subparsers = parser.add_subparsers(dest='subparser_name',help='')

    stat_parser = subparsers.add_parser('stat', help='show flow line projects stat')
    stat_parser.add_argument('-p', dest='sub_project_id',default='', help='sub_project_id')
    stat_parser.set_defaults(func=project_stat)

    delete_parser = subparsers.add_parser('delid', help='delet one filter and analysisproject from database')
    delete_parser.add_argument('-spi', dest='sub_project_id',required=True, help='sub_project_id')
    delete_parser.set_defaults(func=delete_one_project_from_databse)

If you have a Optional arguments, a required positional argument, and then take a look at the extra, returned args after parsing when in your callback, it seems to contain info that is not correct.