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.
--
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
Doug Hellmann doug.hellm...@gmail.com added the comment:
Thanks, everyone!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9444
___
___
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
___
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
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
___
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
___
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 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
___
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
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
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
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
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
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.
--
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
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
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
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
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
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
___
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
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
23 matches
Mail list logo
