On 1/6/2015 7:39 AM, Victor Stinner wrote: > More context: > > 2014-12-19 12:43 GMT+01:00 anatoly techtonik <techtonik at gmail.com>: >> https://github.com/nickstenning/honcho/pull/121 > > The link mentions the following changeset: > --- > changeset: 93122:1a3143752db2 > branch: 2.7 > parent: 93112:927cca0b9337 > user: R David Murray <rdmurray at bitdance.com> > date: Fri Oct 17 20:07:08 2014 -0400 > files: Lib/argparse.py Lib/test/test_argparse.py Misc/NEWS > description: > #9351: set_defaults on subparser is no longer ignored if set on parent. > > Before, if a default was set on the parent parser, any default for that > variable set via set_defaults on a subparser would be ignored. Now > the subparser set_defaults is honored. > > Patch by Jyrki Pullianinen. > > > diff -r 927cca0b9337 -r 1a3143752db2 Lib/argparse.py > --- a/Lib/argparse.py Fri Oct 17 16:20:15 2014 -0500 > +++ b/Lib/argparse.py Fri Oct 17 20:07:08 2014 -0400 > @@ -1089,7 +1089,14 @@ class _SubParsersAction(Action): > # parse all the remaining options into the namespace > # store any unrecognized options on the object, so that the top > # level parser can decide what to do with them > - namespace, arg_strings = parser.parse_known_args(arg_strings, > namespace) > + > + # In case this subparser defines new defaults, we parse them > + # in a new namespace object and then update the original > + # namespace for the relevant parts. > + subnamespace, arg_strings = parser.parse_known_args(arg_strings, None) > + for key, value in vars(subnamespace).items(): > + setattr(namespace, key, value) > + > if arg_strings: > vars(namespace).setdefault(_UNRECOGNIZED_ARGS_ATTR, []) > getattr(namespace, _UNRECOGNIZED_ARGS_ATTR).extend(arg_strings) > --- > > Which is related to http://bugs.python.org/issue9351 > > Maybe argparse just became more strict? I don't understand the issue. Steven Bethard, the argparse maintainer, defined the old behavior of ignoring subparser defaults (where there are also top level defaults) as a bug "counter to what people probably expect". If the old behavior had been documented, changing it in a bug-fix release would have been a mistake. But looking at the patch, the doc seems to have been silent on the issue. This is not the first time someone considered a 'bug fix' to be a 'regression', which it might be from their viewpoint. The last comment on the github thread suggests that an easy fix was found. -- Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4