classification
Title: argparse: repeatedly specifying the same argument ignores the previous ones
Type: behavior Stage: needs patch
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: bethard, flox, mapleoin
Priority: normal Keywords: patch

Created on 2012-07-07 08:45 by mapleoin, last changed 2012-07-23 00:04 by bethard. This issue is now closed.

Files
File name Uploaded Description Edit
disallow_duplicate_positionals.diff mapleoin, 2012-07-07 15:06 look for duplicate positionals - treat them like options conflicts review
Messages (6)
msg164791 - (view) Author: Ionuț Arțăriși (mapleoin) Date: 2012-07-07 08:45
To reproduce:

>>> import argparse
[74536 refs]
>>> parser = argparse.ArgumentParser()
[74809 refs]
>>> parser.add_argument("foo")
>>> parser.add_argument("foo")
>>> parser.parse_args(["bar"])

usage: ipython [-h] foo foo
ipython: error: too few arguments
An exception has occurred, use %tb to see the full traceback.

SystemExit: 2

>>> parser.parse_args(["bar", "baz"])
>>> Namespace(foo='baz')

So it actually makes you provide two arguments, but it loses/ignores the first one and there's no way to get it back.
msg164797 - (view) Author: Florent Xicluna (flox) * (Python committer) Date: 2012-07-07 09:51
Confirmed.
It should probably raise an ArgumentError like this one.

http://docs.python.org/library/argparse.html#conflict-handler
msg164864 - (view) Author: Ionuț Arțăriși (mapleoin) Date: 2012-07-07 14:58
So I was looking into this and it seems that there are (at least) two contradicting test cases. When inheriting a parser from two parents, there are two different behaviours for positionals and for options.

In the case of positionals, there is this test:

def test_same_argument_name_parents(self):
        parents = [self.wxyz_parent, self.z_parent]
        parser = ErrorRaisingArgumentParser(parents=parents)
        self.assertEqual(parser.parse_args('1 2'.split()),
                         NS(w=None, y=None, z='2'))

and this is the context from higher up:

self.wxyz_parent.add_argument('z')
...
self.z_parent.add_argument('z')

So the tests don't expect an error when two parents provide the same argument. Instead, the eating up of the first argument (in this case '1') seems to be condoned?


When I tried to change the conflict_handler during parent action merging to 'resolve' I got another test failing:

def test_conflicting_parents(self):
        self.assertRaises(
            argparse.ArgumentError,
            argparse.ArgumentParser,
            parents=[self.w_parent, self.wxyz_parent])

context:

self.wxyz_parent.add_argument('--w')
...
self.w_parent.add_argument('--w')

This tests that two parents which provide the exact same option will raise an error.


So I think the first test is wrong and should be modified to expect an error in the case where two arguments with the same name are provided. Or is there some use case where this behaviour makes sense?
msg164866 - (view) Author: Ionuț Arțăriși (mapleoin) Date: 2012-07-07 15:06
Here's a stab at a patch to consider conflicts between positionals. Right now conflict resolution is handled the same as in the case of options.
msg166176 - (view) Author: Steven Bethard (bethard) * (Python committer) Date: 2012-07-22 22:37
I don't think this is a bug. You've specified two arguments with the same destination, "foo". This means that argparse will parse the first one, assign it to the attribute "foo" and then parse the second one and assign it to the attribute "foo" again, overwriting the previous one. So you only see the second one, but the first one wasn't ignored.

If you didn't want them to overwrite the same attribute, you either need to declare them as action="append" so that they both add to the same attribute, or you need to declare them with different destinations (and use metavar="foo" if you want them to display the same way).
msg166187 - (view) Author: Steven Bethard (bethard) * (Python committer) Date: 2012-07-23 00:04
I'm going to close this issue, since argparse is doing what you've asked it to, even if that wasn't what you expected.

But I think the documentation for this kind of thing could be improved. If you'd like to help document the workaround for your problem that I described, please contribute to Issue 15428.
History
Date User Action Args
2012-07-23 00:04:14bethardsetstatus: open -> closed
resolution: not a bug
messages: + msg166187
2012-07-22 22:37:36bethardsetmessages: + msg166176
2012-07-07 15:06:22mapleoinsetfiles: + disallow_duplicate_positionals.diff
keywords: + patch
messages: + msg164866
2012-07-07 14:58:47mapleoinsetmessages: + msg164864
2012-07-07 09:51:14floxsetversions: + Python 3.3
nosy: + flox

messages: + msg164797

components: + Library (Lib)
stage: needs patch
2012-07-07 08:45:40mapleoincreate