[issue9444] argparse does not honor prefix_chars when adding default options
Steven Bethard steven.beth...@gmail.com 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
R. David Murray rdmur...@bitdance.com 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 rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Doug Hellmann doug.hellm...@gmail.com added the comment: Thanks, everyone! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Doug Hellmann doug.hellm...@gmail.com added the comment: Yes, that doc change is clear. Thanks! -- nosy: +ted.turocy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Catherine Devlin fredv8vi...@liquidid.net 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 rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Changes by R. David Murray rdmur...@bitdance.com: -- stage: unit test needed - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Changes by R. David Murray rdmur...@bitdance.com: Removed file: http://bugs.python.org/file18298/argparse_char_fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
R. David Murray rdmur...@bitdance.com 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 happy to commit this if you are OK with it, since I was mentoring the people who wrote it. -- nosy: +r.david.murray stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Steven Bethard steven.beth...@gmail.com added the comment: Yes, this looks fine, assuming a test is also added. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Doug Hellmann doug.hellm...@gmail.com 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. I don't know if that's a bug or the desired behavior. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Doug Hellmann doug.hellm...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Theodore Turocy drarbi...@gmail.com 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 option should be to use a doubled prefix character in front of the long-form option. For instance, if prefix_chars='+' and add_help=True, then the automatically provided help arguments will be '+h' and '++help'. Certainly, if one explicitly adds an option '//myopt', we would not expect '::myopt' to also be accepted. I'm talking here only about the options that argparse adds as a convenience. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Doug Hellmann doug.hellm...@gmail.com 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, that's OK, and maybe the docs can be made more specific. It does, however, open the question of how to pick the prefix to use for automatically-generated options. Maybe the current behavior is best after all, so the programmer disabling the '-' prefix character realizes they need to handle the help and version options explicitly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Steven Bethard steven.beth...@gmail.com 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 believe the current behavior is buggy - an
argument that you can never use is added to the parser automatically:
parser = argparse.ArgumentParser(prefix_chars='+')
Traceback (most recent call last):
File stdin, line 1, in module
File /Users/bethard/Documents/projects/python/2.X/Lib/argparse.py, line
1569, in __init__
help=_('show this help message and exit'))
File /Users/bethard/Documents/projects/python/2.X/Lib/argparse.py, line
1246, in add_argument
kwargs = self._get_optional_kwargs(*args, **kwargs)
File /Users/bethard/Documents/projects/python/2.X/Lib/argparse.py, line
1369, in _get_optional_kwargs
raise ValueError(msg % tup)
ValueError: invalid option string '-h': must start with a character '+'
Yes you could explicitly specify add_help=True, but I think using an
appropriate prefix character is actually the right behavior.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9444
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Doug Hellmann doug.hellm...@gmail.com 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 tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Steven Bethard steven.beth...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Doug Hellmann doug.hellm...@gmail.com added the comment: Sorry I'm not being clear: I do like the patch, I think the exception should not be raised. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Theodore Turocy drarbi...@gmail.com 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 option if '-' is not in prefix_chars. -- Added file: http://bugs.python.org/file18317/argparse_char_fix+doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Changes by Catherine Devlin fredv8vi...@liquidid.net: -- nosy: -ted.turocy Added file: http://bugs.python.org/file18320/argparse_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Doug Hellmann doug.hellm...@gmail.com added the comment: One solution would be to use the first character of prefix_chars when building those default options. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +bethard stage: - unit test needed type: - behavior versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Theodore Turocy drarbi...@gmail.com 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 long options simply be disabled? Also, for backwards compatibility, to implement Doug Hellmann's suggestion, '-' should be used for '-h' and '--help' whenever '-' is listed in prefix_chars (so, e.g., prefix_chars='+-' will result in the same behavior as previous versions). I have a working patch for this but wouldn't mind someone else's thoughts first. -- nosy: +ted.turocy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Theodore Turocy drarbi...@gmail.com 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 an argument like '::help' would be a valid long argument. I'm attaching a patch which fixes the originally reported problem as follows: * If '-' is in prefix_chars, then the help and version arguments are '-h', '--help', '-v', '--version' * If '-' is not in prefix_chars, then the first char in prefix_chars is used to lead the option, e.g., '+h', '++help', '+v', '++version' if prefix_chars starts with '+'. Catherine Devlin is also sprinting here at PyOhio and will have a test fixture separately. -- keywords: +patch Added file: http://bugs.python.org/file18298/argparse_char_fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
