In the argparse module, the argument '--' is interpreted as a signal that everything after it is a positional argument. '--' is literally written into the argparse code, in _parse_known_args. This means that a user who wishes to use '--' in some other way is out of luck. 

I suggest the addition of an argument to __init__ (or a method call, or something) that allows '--' to be replaced with some string of the user's choice.

> This means that a user who wishes to use '--' in some other way is out of luck. 

I think that's a feature, not a limitation.

Command line arguments should use broadly consistent conventions. I don't want one program to use '--' for "end of options" and another program to use it for "something else".

Suppose you want to use '--' for "foo", and '%%' (say) as the end of options terminator. Whatever foo is. Okay, just swap them -- keep the usual convention where '--' is the options terminator, and use '%%' for foo. That way your users won't be surprised and confused by your application working differently from the great bulk of commandline applications. (Users never read the manual.)

But maybe I'll change my mind if you can show that there's already a very common, and useful, alternative convention of '--' for foo, for some definition of foo.

argparse roughly follows POSIX practice:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

    Guideline 10:
    The first -- argument that is not an option-argument should be 
    accepted as a delimiter indicating the end of options. Any 
    following arguments should be treated as operands, even if they 
    begin with the '-' character.

I don't think this kind of thing is fixed, but there should be good reason to make an enhancement.  For many users argparse is already too complicated, and the docs are hard to understand.  Yet another parameter can get lost.

There are some known problems with this '--', specially when there are more than one.  It may also have problems when used with subparers, though I forget the details.

It wouldn't hard to substitute a CONST variable for this '--', and wouldn't require changes to the API.  

Another possibility is to change this '--' to 'parser.prefix_chars[0]*2'.  Documenting that would be more work than implementing it.  And we'd have to add a unittest case.

The POSIX guideline suggests that -- should be available as an option argument. One should be able to say "command --opt --" in order to make '--' the value of the '--opt' option. 

> There are some known problems with this '--', specially when there are more than one.

Yes. That is exactly the problem I have.

The earlier issue for '--' as arguement

http://bugs.python.org/issue14364

With the patch I suggested there '-f--' and '--foo=--' work as arguments.  '--foo --' is still interpreted as a positionals switch.

In optparse parsing, a flagged option gets all the remaining strings, and consume what it needs.  In the argparse parser, strings are classed as flag and argument and '--'.  The top level allocates strings to Actions.  '--' is handled at the top level.  This difference in parsing makes it impossible to complete replicate POSIX action.

See also http://bugs.python.org/issue13922