[Python-Dev] python 2.7.9 regression in argparse?

[Ryan Gonzalez]

I thought of this exact comment when I read the "bug fix considered a
regression."

On Tue, Jan 6, 2015 at 2:41 PM, Guido van Rossum <guido at python.org> wrote:

> There's an obligatory XKCD reference for this: http://xkcd.com/1172/
>
> On Tue, Jan 6, 2015 at 12:25 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
>> guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150106/739f469b/attachment.html>