This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author paul.j3
Recipients bethard, ezio.melotti, mikn, nailor, paul.j3, petri.lehtinen, python-dev, r.david.murray
Date 2014-10-24.23:24:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1414193064.31.0.975192942928.issue9351@psf.upfronthosting.co.za>
In-reply-to
Content
A possible problem with this patch is that it overrides any Namespace given by the user.  In the test example:

    parser.parse_args(['X'], namespace=argparse.Namespace(foo=3))

the result is 'foo=2', the setdefault from the subparser.  Previously, and with a single level parser, the result would be 'foo=3'.  This is also true for an ordinary argument default in the subparser.

It could be argued that a user is unlikely to use both the 'namespace=...' parameter, and 'setdefault' for the same variable, especially one that isn't an argument 'dest'.  But the fact that the  custom namespace does not override regular subparser argument defaults bothers me.

Also, should an untested change like this be applied to 3.4 and 2.7?  This is not a backward compatible bug fix.

The test case also touches on a real bug in the recent releases - subparsers are now optional.  'parser.parse_args([])' runs without complaint about the missing 'X'.  Actually it is convenient for testing this case.  But it is still an incompatibility with earlier behavior

http://bugs.python.org/issue9253
History
Date User Action Args
2014-10-24 23:24:24paul.j3setrecipients: + paul.j3, bethard, ezio.melotti, r.david.murray, nailor, python-dev, petri.lehtinen, mikn
2014-10-24 23:24:24paul.j3setmessageid: <1414193064.31.0.975192942928.issue9351@psf.upfronthosting.co.za>
2014-10-24 23:24:24paul.j3linkissue9351 messages
2014-10-24 23:24:23paul.j3create