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 bethard
Recipients Arfrever, arnau, barry, benjamin.peterson, bethard, chris.jerdonek, georg.brandl, python-dev, r.david.murray
Date 2012-09-12.14:48:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I see. So right now, both string defaults and non-string defaults are being converted with the type= function. That seems suspect to me since the documentation explicitly says "type= can take any callable that takes a single string argument and returns the converted value", so non-string defaults don't make sense to pass to that function.

I believe test_type_function_call_with_non_string_default() comes from Arnaud Fontaine. Arnaud, can you comment on the intent of that test?

My thoughts:

* We should not be converting non-string defaults, or the documentation's description of the type= argument doesn't make sense.

* For the string defaults, I can see the argument for not converting them, and the argparse docs never show them being converted from strings. I thought there was a discussion somewhere where someone had requested the current behavior, but I can't for the life of me find that discussion, so perhaps I'm imagining it...

In terms of potential for breaking code, I'm not too worried about removing type conversion for non-string defaults - this never happened before the fix for #12776 and #11839, so I doubt much code depends on it. I am more worried about removing type conversion for string defaults - this has worked for a long time, so there probably is some code that depends on it.
Date User Action Args
2012-09-12 14:48:37bethardsetrecipients: + bethard, barry, georg.brandl, benjamin.peterson, Arfrever, r.david.murray, chris.jerdonek, arnau, python-dev
2012-09-12 14:48:37bethardsetmessageid: <>
2012-09-12 14:48:36bethardlinkissue15906 messages
2012-09-12 14:48:35bethardcreate