paul j3 added the comment:

The patch isn't a good unittest case because it produces an Error, not a 
Failure.  It does, though, raise a valid question about how a 
Mutually_exclusive_group tests for the use of its arguments.

As you note, argparse does use the `is` test: `argument_values is not 
action.default`.  argument_values is the result of passing an argument_string 
through its 'type' function.

This reworks your test case a bit:

    group = parser.add_mutually_exclusive_group()
    group.add_argument('--foo', default='test')
    group.add_argument('--bar', type=int, default=256)
    group.add_argument('--baz', type=int, default=257)

'--foo test --baz 257' will give the `argument --foo: not allowed with argument 
--baz` error message, but '--foo test --baz 256' does not.

So which is right?  Should it complain because 2 exclusive arguments are being 
used?  Or should it be excused from complaining because the values match their 
defaults?

The other issue is whether the values really match the defaults or not.  With 
an `is` test, the `id`s must match. The ids for small integers match all the 
time, while ones >256 differ.

Strings might have the same id or not, depending on how they are created.  If I 
create `x='test'`, and `y='--foo test'.split()[1]`.  `x==y` is True, but `x is 
y` is False.  So '--foo test' argument_value does not match the 'foo.default'.

So large integers (>256) behave like strings when used as defaults in this 
situation.  It's the small integers that have unique ids, and hence don't 
trigger mutually_exclusive_group errors when they should.

This mutually_exclusive_group 'is' test might not be ideal (free from all 
ambiguities), but I'm not sure it needs to be changed.  Maybe there needs to be 
a warning in the docs about mutually_exclusive_groups and defaults other than 
None.

----------
nosy: +paul.j3

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18943>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to