Steven Bethard added the comment: 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. ---------- nosy: +arnau _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15906> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
