There is an standard way to solve this ambiguity.

There is a special marker '--' used to force argument parsing function treat all arguments given in command after this marker as positional arguments. It was invented specially for tasks where you need to force argument parsing engine ignore option indicator and treat argument as positional.

I know this argument as standard 'de facto', but can't find any documents about '--' interpretation.
But you can see, that Linux 'libc' standard C library function getopt() knows about this flag:
http://linux.die.net/man/3/getopt
So, any utility using this function knows about '--'.

For example: grep, tee, cat, tail, head, vim, less, rm, rmdir, common shells (sh, bash, csh, dash, ...) and so on. The list is large. Almost any utility except special ones like 'echo' which main function is to print any argument given to utility.

So, I think, that the true way here is to parse all arguments staring with '-'/'--' and listed before special '--' marker as optional, and treat all of arguments listed after '--' as positional ones and do not try to use any secondary indicators to make a decision: 'optional' or not.


For example:
"""
any parameter before '--' special marker starting with '--' is treated as optional
# python3 example.py --bar="one two" xxx
(Namespace(pos='xxx'), ['--bar=one two'])

all parameters after '--' special marker are treated as positional
# python3 example.py -- --bar="one two" xxx
(Namespace(pos='--bar=one two'), ['xxx'])
"""

Yes, my patch does not the solution and argparse should be patched another way.

Where and how can I get unittests for argparse module to check my code modifications before posting them here? I want to try to modify argparse and produce the patch changing argparse behaviour as described above.

Thanks.