Enchancement suggestion for argparse: intuit type from default
MRAB
python at mrabarnett.plus.com
Wed Mar 14 13:26:19 EDT 2012
On 14/03/2012 13:30, Roy Smith wrote:
> In article<87399bgw18.fsf at benfinney.id.au>,
> Ben Finney<ben+python at benfinney.id.au> wrote:
>
>> Right. I dislike proposals for run-time type inference in Python, since
>> they are too magical.
>>
>> Especially since we're talking about user input (arguments from the
>> command line to the program); that requires more explicit declarations
>> and checking, not less.
>>
>> > What if you want an argument --foo that will accept arbitrary types? Then
>> > you would need some way to tell argparse not to infer the type from the
>> > default.
>>
>> So we would then need to special-case the special-case? Even more reason
>> to dislike this proposal.
>>
>> > Explicit declarations should be used only for the uncommon cases where
>> > type inference cannot cope.
>>
>> That's our point of disagreement, then: I think explicit declarations
>> should be required regarding user input.
>
> I wasn't suggesting that the type be inferred from what the user
> entered. I was suggesting it be inferred from what the programmer had
> done (i.e. what value they had given the 'default' parameter).
>
In other words, if there's a default but no explicit type, then the
type is the type of the default.
> It's already inferred that the type is a string if you don't give it any
> value. What possible meaning could:
>
> parser.add_argument('--foo', default=100)
>
> have? If I run the program with:
>
> $ prog
>
> then foo defaults to the integer 100, but if I run it with:
>
> $ prog --foo=100
>
> then I get the string "100"? Surely there's not much of a use case for
> that.
More information about the Python-list
mailing list