[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