parser.add_argument('-e', '--Edge', type = int, default = 0.005, metavar = 'Edge')

Runs fine. Script uses default of 0.005 even when int specified.

But if user tries to change, not an int....

There is a documentation note on type casting along with an example similar to the report https://docs.python.org/3.8/library/argparse.html#default

> If the default value is a string, the parser parses the value as if it were a command-line argument. In particular, the parser applies any type conversion argument, if provided, before setting the attribute on the Namespace return value. Otherwise, the parser uses the value as is:

Maybe so,

But, the issue is, if it trips up a user when they try to use the option,
it should trip up the dev when the default is used...

On Tue, 23 Jun 2020 18:47 Karthikeyan Singaravelan, <report@bugs.python.org>
wrote:

>
> Karthikeyan Singaravelan <tir.karthi@gmail.com> added the comment:
>
> There is a documentation note on type casting along with an example
> similar to the report
> https://docs.python.org/3.8/library/argparse.html#default
>
> > If the default value is a string, the parser parses the value as if it
> were a command-line argument. In particular, the parser applies any type
> conversion argument, if provided, before setting the attribute on the
> Namespace return value. Otherwise, the parser uses the value as is:
>
> ----------
> nosy: +paul.j3, rhettinger, xtreak
> type:  -> behavior
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue41087>
> _______________________________________
>

No, parameters like `type` let the developer control what his users provides.  Violating that produces a runtime error, and exit.

But in general argparse does not try to control values that the developer uses.  There's plenty of time during development to catch error such as this - if they are errors at all.  

'type' does not 'declare' what the attribute will be.  It is a function that is applied to the input string, and converts that to something or other, or raises a TypeError.  It is used only if there is a string value to work on, either from the user, or a string default.  

This is not a bug, so should be closed.

This sort of ambiguity is why I like strongly typed languages and languages
where timtoady is not seen often.

I can guarantee you, that if argparse was implemented in Pascal (and copt
most probably has been), that if type was specified and a default given,
that the default would have to adhere to that type. It is just programming
common sense....

On Wed, 24 Jun 2020 02:20 paul j3, <report@bugs.python.org> wrote:

>
> paul j3 <ajipanca@gmail.com> added the comment:
>
> No, parameters like `type` let the developer control what his users
> provides.  Violating that produces a runtime error, and exit.
>
> But in general argparse does not try to control values that the developer
> uses.  There's plenty of time during development to catch error such as
> this - if they are errors at all.
>
> 'type' does not 'declare' what the attribute will be.  It is a function
> that is applied to the input string, and converts that to something or
> other, or raises a TypeError.  It is used only if there is a string value
> to work on, either from the user, or a string default.
>
> This is not a bug, so should be closed.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue41087>
> _______________________________________
>

Yes, it is common sense in statically typed languages. Python is not statically typed. Many other things are also "common sense" in various paradigms, which doesn't mean they should also be in Python.

So you agree, Python lacks common sense...

On Wed, 24 Jun 2020 at 03:32, Vedran Čačić <report@bugs.python.org> wrote:

>
> Vedran Čačić <vedgar@gmail.com> added the comment:
>
> Yes, it is common sense in statically typed languages. Python is not
> statically typed. Many other things are also "common sense" in various
> paradigms, which doesn't mean they should also be in Python.
>
> ----------
> nosy: +veky
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue41087>
> _______________________________________
>

Python _is_ strongly typed. As soon as you try to use that 0.005 as an index into a list or something else that requires an int, you'll get a TypeError. Strong typing is not the same as static typing. It is a common misconception.

And common sense is always common to something. For humans it is common sense that we have two eyes, but it's not common to spiders. As I said, what is common sense in statically typed languages is not necessarily common to Python.