argparse supports alternate prefix characters. I believe that this is to support on/off switches like -x/+x and Windows-style options like /h (for complete emulation of the Windows command syntax we need support of the : separator and combining options like in dir /s/w/o/p/a:-d, but this is another story). I never seen even double alternate prefix character, like ++foo or //foo in the wild, but there is no issue with supporting this.
The problem is that this allows specifying options that use two different prefix character, like -+foo or +-foo. It is a problem because you cannot distinguish a sigle-dash option from a double-dash option without knowing prefix._chars. And its value is not always available (for example in the Action constructor). BooleanOptionalAction can recognize ++foo and +foo, but it is confused by +^foo (see #138692).
There are no existing tests for mixed alternate prefix characters. I suppose this is not an intentionally added feature, but just an implementation artifact. I think that we should revisit code and only interpret option as a "double-dash long option" if it starts with the same prefix character doubled. This may have no effect on common users, since -+foo can still be interpreted as a "single-dash long option" (with name "+foo"). We should ensure that single-dash long options are not second-class citizens (for example see #138697).
I'm not sure how to classify this issue or what action to take. This requires further research and experimentation. I'm leaving this as a reminder that something needs to be done.
argparsesupports alternate prefix characters. I believe that this is to support on/off switches like-x/+xand Windows-style options like/h(for complete emulation of the Windows command syntax we need support of the:separator and combining options like indir /s/w/o/p/a:-d, but this is another story). I never seen even double alternate prefix character, like++fooor//fooin the wild, but there is no issue with supporting this.The problem is that this allows specifying options that use two different prefix character, like
-+fooor+-foo. It is a problem because you cannot distinguish a sigle-dash option from a double-dash option without knowingprefix._chars. And its value is not always available (for example in theActionconstructor).BooleanOptionalActioncan recognize++fooand+foo, but it is confused by+^foo(see #138692).There are no existing tests for mixed alternate prefix characters. I suppose this is not an intentionally added feature, but just an implementation artifact. I think that we should revisit code and only interpret option as a "double-dash long option" if it starts with the same prefix character doubled. This may have no effect on common users, since
-+foocan still be interpreted as a "single-dash long option" (with name "+foo"). We should ensure that single-dash long options are not second-class citizens (for example see #138697).I'm not sure how to classify this issue or what action to take. This requires further research and experimentation. I'm leaving this as a reminder that something needs to be done.