[Python-Dev] Issue 15906; regression in argparse in Python 3.3, 3.2, and 2.7
Terry Reedy
tjreedy at udel.edu
Tue Sep 11 23:30:29 CEST 2012
On 9/11/2012 3:31 PM, Barry Warsaw wrote:
> On Sep 11, 2012, at 01:17 PM, Terry Reedy wrote:
>> As I see it, storing is done *with* a default or explicit value, appending is
>> done *to* a start value *with* whatever. Perhaps reusing 'default' instead of
>> using a new name such as 'start' was a bit too clever for our own good ;-).
Such cleverness is something that I might have done, having been
'raised' on IBM mainframes with statements with 8-10 position-only
parameters (JCL DD? don't quite remember), and having had to carefully
count commas writing things like
XX arg1, arg2,,,arg5,,,arg8,,
The cost of positions rewards multiplexing the meaning of positions.
The availability of keyword-only parameters changes the tradeoffs.
>>> The fix for issue 12776 broke the last two lines of the second example,
>>> because in the no-command-line-arguments-given case, arg.test is the
>>> *string* "[]" and not the actual empty list object.
>>
>> This seems even more wrong (as in slightly crazy) as it switches the meaning
>> of 'default' within one parser example rather than between parser examples.
>
> And yet, that's how it works in 2.7, 3.2, and 3.3.1.
In all 2.7 or 3.2?
>
>>> It seems to me that the semantics could reasonably be implied to mean that
>>> the type converter should only be applied to the default value when
>>> action='store', as is the default. Then in the second example, because
>>> action='append', the type conversion would not be applied (it makes no
>>> sense to do so).
>>
>> I arrive at the same conclusion, I believe, by saying that for a given
>> parser, the type converter should always or never be applied to 'default',
>> which should mean converting or not when the parser is created. Append to
>> 'default as base or start' should mean not converting.
>
> Does that mean that for fixing the regression, you favor applying the type
> conversion only for action='store' or by only applying it when the default is
> a string?
How about a third rule which amounts to the second *plus* (maybe) the
first: apply the conversion when it fulfills the purpose of having type
conversions, which is to make sure that the caller get objects of the
desired class. Also, only add necessary restrictions to argparse users.
In particular: parser.parse_args gets a sequence of strings. But callers
of .parse_args often want non-string objects. argparse could return args
as named strings and make the user convert to the types wanted, but
there are good reasons to do the conversion at the point of parsing.
So the conversion function *must* accept strings, but it seems an
unnecessary restriction to require it to accept anything else, including
its output type or a non-string 'default'.
When the 'default' is a substitute for user input, as with Store, *and*
it is a string, it should be converted just like user input. But the
parser designer should not have to convert a non-string default object
to a string just so it can be converted back to the real default
non-string object (another unnecessary restriction). (If type=int, there
is no sense in requiring default='100' instead of default=100.) Indeed,
the default object might not even be a possible output of the conversion
function (for instance, type=int, default=None).
If the 'default' is not a backup/replacement for a string input to
parse_args, as with append, then it seems it should not be converted either.
> It seems better to only apply the type conversion for action='store' but more
> backward compatible for the original behavior to only apply it when default is
> a string.
Are there any other actions where the default might be a string that
should be converted the same way as user input? If not, both rules apply.
As I said, I am not familiar with the details of argparse (or the
previous bugfix), so I let you sort out how these thoughts apply to
previous, current, and desired future behavior and doc claims.
--
Terry Jan Reedy
More information about the Python-Dev
mailing list