Feature Request: ignore (or extract) not specified extra options instead of fail

Hi there,

It would be great to be able to ignore not specified options when parsing arguments.

My use case is that some runtime invokes my python script with additional options for which I don’t have any control. I’d just like to ignore them.

For instance, if I use the naval fate example from README.md, I’d like the following command to be valid:

• naval_fate.py ship shoot 1 2 --unwanted-option
• naval_fate.py ship --unwanted-option shoot 1 2
• naval_fate.py --unwanted-option ship shoot 1 2

Another idea would be to, instead of ignoring them, simply extract them in another dict as the argparse library do via the parse_known_args method.

[mvillion]

Imagine I have a script that censors bad words and raises an error when bad words are present in file :

python censor_bad_words.py <filename> [--language=<lang>]

and another script which simply prints the content:

python print_file.py <filename> [--color=<col>]

Now, I want to build a script that does both: python print_censor_bad_words.py <filename> [–language=<lang>] [–color=<col>]

[From the two doc strings, I can programmatically create a combined doc for docopt.]

If I call: python print_censor_bad_words.py my_file.txt --language=eng --color=blue

I could simply transfer all parameters of the call to sub-scripts:

python censor_bad_words.py my_file.txt --language=eng --color=blue
python print_file.py my_file.txt --language=eng --color=blue

censor_bad_words.py will complain that it does not know what --color is. print_file.py will complain that it does not know what --language is.

---

When a script is given all the mandatory arguments it needs, if an unknown/unwanted argument is passed, it can:

1. strict syntax: raise an error
2. practical: raise a warning and perform the task
3. perform the task

---

In docopt.py code: if matched and left == []: # better error message if left? return Dict((a.name, a.value) for a in (pattern.flat() + collected))

Programmer already had interrogations about what to do when there are unwanted arguments left.

[mvillion]

“Would you apply it only on option -s short option, --long-option or would it also apply to <argument> or command too?” All arguments that do not match the definition are rejected. [ This is not he object of this request but it raises the question about what to do with the “left” arguments: a. just ignore them b. pass them to the script anyway (in order to enable non documented arguments that the developer may not want to support)

I assume a. ]

only optional option or mandatory one? As long as the script has the mandatory parameters that it wants, and it parses all the optional parameters that it knows, it is sufficient not to raise an error.

I bump into this when creating a C server that calls python scripts. I want a single python script as entry point as I do not want the client to execute any possible python script. In this script, there is argument that contains the name of the sub-script to be called. This script then calls the appropriate script with the remaining parameters. For this top-level, if I want to use docopt, I need a doc with only the sub-script name but then it refuses to execute as there are other parameters.