Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #21584 > unrolled thread

Enchancement suggestion for argparse: intuit type from default

Back to article view | Back to comp.lang.python

Contents

  Enchancement suggestion for argparse: intuit type from default roy@panix.com (Roy Smith) - 2012-03-13 17:08 -0400
    Re: Enchancement suggestion for argparse: intuit type from default Ben Finney <ben+python@benfinney.id.au> - 2012-03-14 08:35 +1100
      Re: Enchancement suggestion for argparse: intuit type from default Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-14 12:53 +0000
        Re: Enchancement suggestion for argparse: intuit type from default Ben Finney <ben+python@benfinney.id.au> - 2012-03-15 00:19 +1100
          Re: Enchancement suggestion for argparse: intuit type from default Roy Smith <roy@panix.com> - 2012-03-14 09:30 -0400
            Re: Enchancement suggestion for argparse: intuit type from default MRAB <python@mrabarnett.plus.com> - 2012-03-14 17:26 +0000
            Re: Enchancement suggestion for argparse: intuit type from default Ian Kelly <ian.g.kelly@gmail.com> - 2012-03-14 13:03 -0600
    Re: Enchancement suggestion for argparse: intuit type from default rusi <rustompmody@gmail.com> - 2012-03-14 03:22 -0700
    Re: Enchancement suggestion for argparse: intuit type from default Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-03-14 13:26 +0100
    Re: Enchancement suggestion for argparse: intuit type from default John Nagle <nagle@animats.com> - 2012-03-14 16:32 -0700
      Re: Enchancement suggestion for argparse: intuit type from default Roy Smith <roy@panix.com> - 2012-03-14 20:52 -0400
        Re: Enchancement suggestion for argparse: intuit type from default Ben Finney <ben+python@benfinney.id.au> - 2012-03-15 12:22 +1100
          Re: Enchancement suggestion for argparse: intuit type from default Cameron Simpson <cs@zip.com.au> - 2012-03-15 16:59 +1100
          Re: Enchancement suggestion for argparse: intuit type from default Robert Kern <robert.kern@gmail.com> - 2012-03-15 10:06 +0000
            Re: Enchancement suggestion for argparse: intuit type from default Roy Smith <roy@panix.com> - 2012-03-15 09:28 -0400
              Re: Enchancement suggestion for argparse: intuit type from default Cameron Simpson <cs@zip.com.au> - 2012-03-16 08:18 +1100
        Re: Enchancement suggestion for argparse: intuit type from default MRAB <python@mrabarnett.plus.com> - 2012-03-15 02:10 +0000

#21584 — Enchancement suggestion for argparse: intuit type from default

Using argparse, if I write:

    parser.add_argument('--foo', default=100)

it seems like it should be able to intuit that the type of foo should
be int (i.e. type(default)) without my having to write:

    parser.add_argument('--foo', type=int, default=100)

Does this seem like a reasonable enhancement to argparse?

[toc] | [next] | [standalone]

#21585

roy@panix.com (Roy Smith) writes:

> Using argparse, if I write:
>
>     parser.add_argument('--foo', default=100)
>
> it seems like it should be able to intuit that the type of foo should
> be int (i.e. type(default))
[…]

-0.5.

That feels too magical to me. I don't see a need to special-case that
usage. There's not much burden in being explicit for the argument type.

-- 
 \           “Value your freedom or you will lose it, teaches history. |
  `\     “Don't bother us with politics,” respond those who don't want |
_o__)                            to learn.” —Richard M. Stallman, 2002 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#21594

On Wed, 14 Mar 2012 08:35:12 +1100, Ben Finney wrote:

> roy@panix.com (Roy Smith) writes:
> 
>> Using argparse, if I write:
>>
>>     parser.add_argument('--foo', default=100)
>>
>> it seems like it should be able to intuit that the type of foo should
>> be int (i.e. type(default))
> […]
> 
> -0.5.
> 
> That feels too magical to me. I don't see a need to special-case that
> usage. There's not much burden in being explicit for the argument type.

And yet you are programming in Python instead of Java, Pascal or Ada :)

It's not magic at all, it's science! Or to be precise, it's a very simple 
form of type inference, similar to (but much more basic than) that used 
by languages such as Go, Haskell, Ocaml, and ML.

http://en.wikipedia.org/wiki/Type_inference

Given the premise that arguments in argparser are typed, if the argument 
can take the value 100 (the default), it is logical that it can't be a 
string (because 100 is not a string) or a boolean (because 100 is not a 
boolean) or a list (because... well, you get the point).

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.

Python *names* are not typed, but objects are. Python infers the type of 
the object from its syntax. We write:

n = 100

and not:

n = int 100

Assuming that argparse arguments are typed, and that there is a way to 
over-rule the type-inference, there is no need to declare types in the 
common case. Explicit declarations should be used only for the uncommon 
cases where type inference cannot cope.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#21596

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> On Wed, 14 Mar 2012 08:35:12 +1100, Ben Finney wrote:
> > That feels too magical to me. I don't see a need to special-case
> > that usage. There's not much burden in being explicit for the
> > argument type.
>
> And yet you are programming in Python instead of Java, Pascal or Ada
> :)

That's a good point :-)

> It's not magic at all, it's science! Or to be precise, it's a very simple 
> form of type inference

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.

-- 
 \              “Ridicule is the only weapon which can be used against |
  `\       unintelligible propositions.” —Thomas Jefferson, 1816-07-30 |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#21598

In article <87399bgw18.fsf@benfinney.id.au>,
 Ben Finney <ben+python@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).

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.

[toc] | [prev] | [next] | [standalone]

#21613

On 14/03/2012 13:30, Roy Smith wrote:
> In article<87399bgw18.fsf@benfinney.id.au>,
>   Ben Finney<ben+python@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.

[toc] | [prev] | [next] | [standalone]

#21622

On Wed, Mar 14, 2012 at 7:30 AM, Roy Smith <roy@panix.com> wrote:
> 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.

What about:

parser.add_argument('--foo', default=None)

Probably it should not infer NoneType as the argument type in this
case.  So would it just ignore the default in this case and let the
type remain str?

Also, how would the inference interact with different actions?  For example:

parser.add_argument('--foo', action='append', default=['one'])

I'm not exactly sure what a use case for this might be, but anyway,
the type here should clearly be str, not list.  And then what about
this variation:

parser.add_argument('--foo', action='append', default=[1])

Should it try to infer that because the list contains an int, the type
should be int?  And even if you manage to get the inference working
flawlessly and expectedly for append, what about custom actions?

It seems to me that there are a large number of edge cases here that
will end up hurting predictability for the end user.

Cheers,
Ian

[toc] | [prev] | [next] | [standalone]

#21592

On Mar 14, 2:08 am, r...@panix.com (Roy Smith) wrote:
> Using argparse, if I write:
>
>     parser.add_argument('--foo', default=100)
>
> it seems like it should be able to intuit that the type of foo should
> be int (i.e. type(default)) without my having to write:
>
>     parser.add_argument('--foo', type=int, default=100)
>
> Does this seem like a reasonable enhancement to argparse?

Sounds reasonable to me

[toc] | [prev] | [next] | [standalone]

#21595

Am 13.03.2012 22:08, schrieb Roy Smith:
> Using argparse, if I write:
>
>      parser.add_argument('--foo', default=100)
>
> it seems like it should be able to intuit that the type of foo should
> be int (i.e. type(default)) without my having to write:
>
>      parser.add_argument('--foo', type=int, default=100)
>
> Does this seem like a reasonable enhancement to argparse?

The following would turn into an error:

   # in foo.py:
   p.add_argument('--offset', 0)

   # calling foo.py:
   foo.py --offset 1.5

OTOH, this would be obvious even from halfway serious testing, so I'm +1 
for making this change. Have you looked at existing use of this and 
where it would break anything? When the argument doesn't match the type, 
is the error message sufficiently understandable?

Uli

[toc] | [prev] | [next] | [standalone]

#21633

On 3/13/2012 2:08 PM, Roy Smith wrote:
> Using argparse, if I write:
>
>      parser.add_argument('--foo', default=100)
>
> it seems like it should be able to intuit that the type of foo should
> be int (i.e. type(default)) without my having to write:
>
>      parser.add_argument('--foo', type=int, default=100)
>
> Does this seem like a reasonable enhancement to argparse?

    default=None

presents some problems.

				John Nagle

[toc] | [prev] | [next] | [standalone]

#21640

In article <4f612a9d$0$12033$742ec2ed@news.sonic.net>,
 John Nagle <nagle@animats.com> wrote:

> On 3/13/2012 2:08 PM, Roy Smith wrote:
> > Using argparse, if I write:
> >
> >      parser.add_argument('--foo', default=100)
> >
> > it seems like it should be able to intuit that the type of foo should
> > be int (i.e. type(default)) without my having to write:
> >
> >      parser.add_argument('--foo', type=int, default=100)
> >
> > Does this seem like a reasonable enhancement to argparse?
> 
>     default=None
> 
> presents some problems.

I'll admit I hadn't considered that, but I don't see it as a major 
problem.  The type intuition could be designed to only work for types 
other than NoneType.

[toc] | [prev] | [next] | [standalone]

#21641

Roy Smith <roy@panix.com> writes:

> I'll admit I hadn't considered that, but I don't see it as a major
> problem. The type intuition could be designed to only work for types
> other than NoneType.

−1, then. It's growing too many special cases, and is no longer simple
to describe, so that indicates it's probably a bad idea.

-- 
 \     “[W]e are still the first generation of users, and for all that |
  `\      we may have invented the net, we still don't really get it.” |
_o__)                                                   —Douglas Adams |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#21645

On 15Mar2012 12:22, Ben Finney <ben+python@benfinney.id.au> wrote:
| Roy Smith <roy@panix.com> writes:
| > I'll admit I hadn't considered that, but I don't see it as a major
| > problem. The type intuition could be designed to only work for types
| > other than NoneType.
| 
| −1, then. It's growing too many special cases, and is no longer simple
| to describe, so that indicates it's probably a bad idea.

If `type` is not supplied and `default` is present and not None, `type`
shall be the type of `default`.

That seems straightforward to me. It's a single sentence, easy to read
and understand, and potentially saves a lot of code verbiage (gratuitous
type= prarameters). I say "gratuitous" because unless `default` is a
sentinel for "no option supplied", the `type` should always match
type(default). Or am I wrong about that?

Cheers,
-- 
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

You only live once in life, but if you do it right, once is enough!
        - Rob Castro <rdc8@columbia.edu>

[toc] | [prev] | [next] | [standalone]

#21649

On 3/15/12 5:59 AM, Cameron Simpson wrote:
> On 15Mar2012 12:22, Ben Finney<ben+python@benfinney.id.au>  wrote:
> | Roy Smith<roy@panix.com>  writes:
> |>  I'll admit I hadn't considered that, but I don't see it as a major
> |>  problem. The type intuition could be designed to only work for types
> |>  other than NoneType.
> |
> | −1, then. It's growing too many special cases, and is no longer simple
> | to describe, so that indicates it's probably a bad idea.
>
> If `type` is not supplied and `default` is present and not None, `type`
> shall be the type of `default`.
>
> That seems straightforward to me. It's a single sentence, easy to read
> and understand, and potentially saves a lot of code verbiage (gratuitous
> type= prarameters). I say "gratuitous" because unless `default` is a
> sentinel for "no option supplied", the `type` should always match
> type(default). Or am I wrong about that?

Yes. Not all type(default) types can be called with a string to produce a valid 
value. Note that "type=" is really a misnomer. argparse doesn't really want a 
type object there; it wants a converter function that takes a string to an object.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[toc] | [prev] | [next] | [standalone]

#21666

In article <mailman.665.1331806024.3037.python-list@python.org>,
 Robert Kern <robert.kern@gmail.com> wrote:

> Yes. Not all type(default) types can be called with a string to produce a 
> valid 
> value. Note that "type=" is really a misnomer. argparse doesn't really want a 
> type object there; it wants a converter function that takes a string to an 
> object.

Orthogonal to my original suggestion, I agree that this is misnamed.  
I'm +1 on the idea of renaming it to conversion= or something like that 
(we'd need to keep type= around as a deprecated synonym for backwards 
compatability).  It's really hard to get your head around "type=open".

[toc] | [prev] | [next] | [standalone]

#21714

On 15Mar2012 09:28, Roy Smith <roy@panix.com> wrote:
| In article <mailman.665.1331806024.3037.python-list@python.org>,
|  Robert Kern <robert.kern@gmail.com> wrote:
| > Yes. Not all type(default) types can be called with a string to produce a 
| > valid 
| > value. Note that "type=" is really a misnomer. argparse doesn't really want a 
| > type object there; it wants a converter function that takes a string to an 
| > object.
| 
| Orthogonal to my original suggestion, I agree that this is misnamed.  
| I'm +1 on the idea of renaming it to conversion= or something like that 
| (we'd need to keep type= around as a deprecated synonym for backwards 
| compatability).  It's really hard to get your head around "type=open".

"factory"? Anyway, far too late to change this now!
-- 
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

all coders are created equal; that they are endowed with certain
unalienable rights, of these are beer, net connectivity, and the
pursuit of bugfixes...  - Gregory R Block

[toc] | [prev] | [next] | [standalone]

#21642

On 15/03/2012 00:52, Roy Smith wrote:
> In article<4f612a9d$0$12033$742ec2ed@news.sonic.net>,
>   John Nagle<nagle@animats.com>  wrote:
>
>>  On 3/13/2012 2:08 PM, Roy Smith wrote:
>>  >  Using argparse, if I write:
>>  >
>>  >       parser.add_argument('--foo', default=100)
>>  >
>>  >  it seems like it should be able to intuit that the type of foo should
>>  >  be int (i.e. type(default)) without my having to write:
>>  >
>>  >       parser.add_argument('--foo', type=int, default=100)
>>  >
>>  >  Does this seem like a reasonable enhancement to argparse?
>>
>>      default=None
>>
>>  presents some problems.
>
> I'll admit I hadn't considered that, but I don't see it as a major
> problem.  The type intuition could be designed to only work for types
> other than NoneType.

True, you could consider that a special case.

If you really do want NoneType, or if the type doesn't otherwise match
the default (or there's no default), then you can still be explicit.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web