[issue9444] argparse does not honor prefix_chars when adding default options

Doug Hellmann added the comment: Thanks, everyone! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue9444] argparse does not honor prefix_chars when adding default options

R. David Murray added the comment: Committed (with the additional test) to py3k in r83657, and 2.7 in r83676. -- stage: commit review -> committed/rejected status: open -> closed ___ Python tracker

[issue9444] argparse does not honor prefix_chars when adding default options

Steven Bethard added the comment: Yep, I'm fine with you committing this (after adding the prefix="+-/" you suggested). I don't have time right now to test the patches, but the code looks about right, and the tests ran fine for you, so I'm fine with it. -- ___

[issue9444] argparse does not honor prefix_chars when adding default options

R. David Murray added the comment: The combined patches look good to me, and I tested the tests and patch. (I accidentally deleted the earlier fix patch, sorry). It would be nice to add one more test case that does prefix="+-/" to make sure - is used when it isn't first. Steven, I'd be hap

[issue9444] argparse does not honor prefix_chars when adding default options

Changes by R. David Murray : Removed file: http://bugs.python.org/file18298/argparse_char_fix.patch ___ Python tracker ___ ___ Python-bugs-list

[issue9444] argparse does not honor prefix_chars when adding default options

Changes by R. David Murray : -- stage: unit test needed -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue9444] argparse does not honor prefix_chars when adding default options

Catherine Devlin added the comment: Attached a unit test patch corresponding to Ted's patch. http://bugs.python.org/file18320/argparse_test.patch -- nosy: +catherine ___ Python tracker ___

[issue9444] argparse does not honor prefix_chars when adding default options

Doug Hellmann added the comment: Yes, that doc change is clear. Thanks! -- nosy: +ted.turocy ___ Python tracker ___ ___ Python-bugs-

[issue9444] argparse does not honor prefix_chars when adding default options

Changes by Catherine Devlin : -- nosy: -ted.turocy Added file: http://bugs.python.org/file18320/argparse_test.patch ___ Python tracker ___ ___

[issue9444] argparse does not honor prefix_chars when adding default options

Theodore Turocy added the comment: I'm uploading a new version of my patch which includes a proposed clarification to the documentation about the behavior in this case. Doug, does this make the documentation clearer to you? It is now explicit about the behavior for formulating the help opti

[issue9444] argparse does not honor prefix_chars when adding default options

Doug Hellmann added the comment: Sorry I'm not being clear: I do like the patch, I think the exception should not be raised. -- ___ Python tracker ___ __

[issue9444] argparse does not honor prefix_chars when adding default options

Steven Bethard added the comment: A doc patch would also be welcome, but I do think it's a bug that "ArgumentParser(prefix_chars='+')" throws an exception, and I think Ted's patch looks fine to me. -- ___ Python tracker

[issue9444] argparse does not honor prefix_chars when adding default options

Doug Hellmann added the comment: Explicitly specifying aliases makes sense, it just wasn't clear that was the intent from the existing documentation. So, I don't think the behavior needs to change, but a doc update might help. -- ___ Python tracke

[issue9444] argparse does not honor prefix_chars when adding default options

Steven Bethard added the comment: It is intentional that you have to specify both "/foo" and "+foo" if you want them to be aliases for the same argument. A common use case for prefix_chars is to define "+x" and "-x" options, which usually mean different things. As far as the current issue, I

[issue9444] argparse does not honor prefix_chars when adding default options

Doug Hellmann added the comment: I was actually surprised that prefix_chars didn't allow *any* of those characters to indicate an option. For example, a program on Unix might use options that start with '-', but also support '/' as a prefix under Windows. If that's the intended behavior, th

[issue9444] argparse does not honor prefix_chars when adding default options

Theodore Turocy added the comment: I was less than clear in what I wrote last night, Doug. What I mean is that the idiom "::foo" for a long argument, instead of the more standard-looking "--foo", appears in the test suite. This suggests to me that the intended behavior for the default help

[issue9444] argparse does not honor prefix_chars when adding default options

Doug Hellmann added the comment: Oh, I should point out that last comment is describing what I see when using the unpatched 2.7 version of the module. -- ___ Python tracker ___

[issue9444] argparse does not honor prefix_chars when adding default options

Doug Hellmann added the comment: I haven't read the existing tests, but I am not seeing the behavior described by Ted in msg112258. If I specify the prefix_chars as '+/' and define a long option '//myopt' then using ++myopt on the command line gives an error that the option is unrecognized.

[issue9444] argparse does not honor prefix_chars when adding default options

Steven Bethard added the comment: Yes, this looks fine, assuming a test is also added. -- ___ Python tracker ___ ___ Python-bugs-list

[issue9444] argparse does not honor prefix_chars when adding default options

Theodore Turocy added the comment: Looking at the test fixtures that exercise argparse, it appears that the intended behavior when '-' is not a prefix_char is to accept a doubling of any of the prefix_chars for long arguments. That is, if '-' is not present in prefix_chars but ':' is, then a

[issue9444] argparse does not honor prefix_chars when adding default options

Theodore Turocy added the comment: What is the appropriate behavior for long options when '-' is not one of the accepted prefix_chars? All of '-h', '--help', '-v', and '--version' are hardcoded in the ctor. If, for instance, prefix_chars='+', should the long options be '++help', or should l

[issue9444] argparse does not honor prefix_chars when adding default options

Changes by R. David Murray : -- nosy: +bethard stage: -> unit test needed type: -> behavior versions: +Python 3.2 ___ Python tracker ___

[issue9444] argparse does not honor prefix_chars when adding default options

Doug Hellmann added the comment: One solution would be to use the first character of prefix_chars when building those default options. -- ___ Python tracker ___

[issue9444] argparse does not honor prefix_chars when adding default options

New submission from Doug Hellmann : If an ArgumentParser is created with a prefix_chars string that does not include '-', the default options created for showing help (-h and --help) and the version (-v and --version) are invalid and generate an exception. -- components: Library (Lib)