Author paul.j3
Recipients arigo, bethard, paul.j3, pitrou
Date 2013-09-08.23:33:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1378683221.9.0.37694010761.issue18943@psf.upfronthosting.co.za>
In-reply-to
Content
This `argument_values` comes from `_get_values()`.  Most of the time is derived from the `argument_strings`.  But in a few cases it is set to `action.default`, specifically when the action is an optional postional with an empty `argument_strings`.

test_argparse.TestMutuallyExclusiveOptionalAndPositional is such a case.  `badger` is an optional positional in a mutually exclusive group.  As such it can be 'present' without really being there (tricky).  Positionals are always processed - otherwise it raises an error.

If this is the case, what we need is a more reliable way of knowing whether `_get_values()` is doing this, one that isn't fooled by this small int caching.

We could rewrite the `is not` test as:

    if not argument_strings and action.nargs in ['*','?'] and  argument_values is action.default:
        pass # _get_values() has set: argument_values=action.default
    else:
        seen_non_default_actions.add(action)
        ...

is a little better, but still feels like a kludge.  Having `_get_values` return a flag that says "I am actually returning action.default" would be clearer, but, I think, too big of a change.
History
Date User Action Args
2013-09-08 23:33:41paul.j3setrecipients: + paul.j3, arigo, pitrou, bethard
2013-09-08 23:33:41paul.j3setmessageid: <1378683221.9.0.37694010761.issue18943@psf.upfronthosting.co.za>
2013-09-08 23:33:41paul.j3linkissue18943 messages
2013-09-08 23:33:41paul.j3create