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 barry
Recipients Arfrever, barry, benjamin.peterson, bethard, georg.brandl
Date 2012-09-11.15:16:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1347376592.28.0.212655487579.issue15906@psf.upfronthosting.co.za>
In-reply-to
Content
Okay, this bug is clearly caused by the patch applied for issue 12776.  Here's the patch set url: http://hg.python.org/cpython/rev/74f6d87cd471

Now, if you look at this, I think this changes the semantics for non-string default with a type converter, but the question then becomes, what is the intended semantics?

The documentation at:

http://docs.python.org/py3k/library/argparse.html#the-add-argument-method

says:

type - The type to which the command-line argument should be converted.

Okay, that makes perfect sense, because the command line arguments will always be strings in need of conversion.  What *doesn't* make sense, IMHO, is that the type conversion should be applied to the default value.  This is not documented behavior, but more importantly, is unnecessary, because the .add_argument() call site can just as easily provide a default that's already been converted.  However, if you do this with the change, then the default value will get converted twice, once explicitly at the .add_argument() call site, and again, implicitly by argparse.

Also, as this bug report indicates, it then becomes impossible to provide a default that is not converted.

So I believe that the test added for issue 12776 is not correct (specifically test_type_function_call_with_non_string_default), and should be removed.  I'm not even sure the original analysis of that bug is correct, but there is a serious semantic ambiguity that needs to be resolved.  Specifically, should you support both the use case given in that bug and this bug's use case, and if so, how?  E.g.  should you even expect this to work:

.add_argument('--foo', type=open, default='/etc/passwd')

?

Maybe another way to look at it is that the conversion should only happen if the action is 'store'.  It definitely should not happen if the action is 'append'.

Let's say that the latter is the intended semantics.  Attached is a patch that implements these semantics, with a test.  If approved, I think we also need to describe the exact semantics in the documentation.  I will do that, add a NEWS entry, and back port.
History
Date User Action Args
2012-09-11 15:16:32barrysetrecipients: + barry, georg.brandl, bethard, benjamin.peterson, Arfrever
2012-09-11 15:16:32barrysetmessageid: <1347376592.28.0.212655487579.issue15906@psf.upfronthosting.co.za>
2012-09-11 15:16:31barrylinkissue15906 messages
2012-09-11 15:16:30barrycreate