I generally enjoy argparse, but one thing I find rather ugly and unpythonic. parser.add_argument ('--plot', action='store_true') Specifying the argument 'action' as a string is IMO ugly.
On Fri, Mar 5, 2010 at 12:51, Neal Becker <ndbecker2@gmail.com> wrote:
I generally enjoy argparse, but one thing I find rather ugly and unpythonic.
parser.add_argument ('--plot', action='store_true')
Specifying the argument 'action' as a string is IMO ugly.
What else would you propose? FWIW, this is the same in optparse.
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker <ndbecker2@gmail.com> wrote:
I generally enjoy argparse, but one thing I find rather ugly and unpythonic.
parser.add_argument ('--plot', action='store_true')
Specifying the argument 'action' as a string is IMO ugly.
What else would you propose? FWIW, this is the same in optparse.
I would have thought use the object itself, instead of a string that spells the object's name.
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker <ndbecker2@gmail.com> wrote:
I generally enjoy argparse, but one thing I find rather ugly and unpythonic.
parser.add_argument ('--plot', action='store_true')
Specifying the argument 'action' as a string is IMO ugly.
What else would you propose? FWIW, this is the same in optparse.
I would have thought use the object itself, instead of a string that spells the object's name.
What object? How would you write the example instead then? -- --Guido van Rossum (python.org/~guido)
On 7 Mar 2010, at 19:49, Guido van Rossum wrote:
How would you write the example instead then?
Boolean flags are a common enough case that I'd be inclined to add a wrapper method, so you could just say: parser.add_bool_argument('--plot') As you can always fall back to the more general add_argument() call, the wrapper could just handle the usual case (default false, presence of option sets flag to True). So the signature would be pretty simple - something like: def add_bool_argument(self, help=None, dest=None): Mark Russell
On 2010-03-08 15:20 PM, Greg Ewing wrote:
Mark Russell wrote:
Boolean flags are a common enough case that I'd be inclined to add a wrapper method,
parser.add_bool_argument('--plot')
+1, this looks good.
I've added it to the argparse bugtracker, along with my suggested spelling add_flag(): http://code.google.com/p/argparse/issues/detail?id=62 -- 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
On Mon, 08 Mar 2010 15:35:46 -0600, Robert Kern <robert.kern@gmail.com> wrote:
On 2010-03-08 15:20 PM, Greg Ewing wrote:
Mark Russell wrote:
Boolean flags are a common enough case that I'd be inclined to add a wrapper method,
parser.add_bool_argument('--plot')
+1, this looks good.
I've added it to the argparse bugtracker, along with my suggested spelling add_flag():
Shouldn't argparse bugs/enhancement tickets be going to bugs.python.org now? -- R. David Murray www.bitdance.com
On Tue, Mar 9, 2010 at 11:31, R. David Murray <rdmurray@bitdance.com> wrote:
On Mon, 08 Mar 2010 15:35:46 -0600, Robert Kern <robert.kern@gmail.com> wrote:
On 2010-03-08 15:20 PM, Greg Ewing wrote:
Mark Russell wrote:
Boolean flags are a common enough case that I'd be inclined to add a wrapper method,
parser.add_bool_argument('--plot')
+1, this looks good.
I've added it to the argparse bugtracker, along with my suggested spelling add_flag():
Shouldn't argparse bugs/enhancement tickets be going to bugs.python.org now?
Probably. Having used the the argparse tracker before, though, it was the first place I thought to file it. -- 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
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum <guido@python.org> wrote:
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker <ndbecker2@gmail.com> wrote:
I generally enjoy argparse, but one thing I find rather ugly and unpythonic.
parser.add_argument ('--plot', action='store_true')
Specifying the argument 'action' as a string is IMO ugly.
What else would you propose? FWIW, this is the same in optparse.
I would have thought use the object itself, instead of a string that spells the object's name.
What object? How would you write the example instead then?
In argparse, unlike optparse, actions are actually defined by objects with a particular API, and the string is just a shorthand for referring to that. So: parser.add_argument ('--plot', action='store_true') is equivalent to: parser.add_argument('--plot', argparse._StoreTrueAction) Because the names are so long and you'd have to import them, I've left them as private attributes of the module, but if there's really demand, we could rename them to argparse.StoreTrueAction, etc. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Mon, Mar 8, 2010 at 7:40 AM, Steven Bethard <steven.bethard@gmail.com> wrote:
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum <guido@python.org> wrote:
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker <ndbecker2@gmail.com> wrote:
I generally enjoy argparse, but one thing I find rather ugly and unpythonic.
parser.add_argument ('--plot', action='store_true')
Specifying the argument 'action' as a string is IMO ugly.
What else would you propose? FWIW, this is the same in optparse.
I would have thought use the object itself, instead of a string that spells the object's name.
What object? How would you write the example instead then?
In argparse, unlike optparse, actions are actually defined by objects with a particular API, and the string is just a shorthand for referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Sorry, that should have been: parser.add_argument('--plot', action=argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left them as private attributes of the module, but if there's really demand, we could rename them to argparse.StoreTrueAction, etc.
Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
-- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
Steven Bethard wrote:
On Mon, Mar 8, 2010 at 7:40 AM, Steven Bethard <steven.bethard@gmail.com> wrote:
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum <guido@python.org> wrote:
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker <ndbecker2@gmail.com> wrote:
I generally enjoy argparse, but one thing I find rather ugly and unpythonic.
parser.add_argument ('--plot', action='store_true')
Specifying the argument 'action' as a string is IMO ugly.
What else would you propose? FWIW, this is the same in optparse. I would have thought use the object itself, instead of a string that spells the object's name. What object? How would you write the example instead then? In argparse, unlike optparse, actions are actually defined by objects with a particular API, and the string is just a shorthand for referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Sorry, that should have been:
parser.add_argument('--plot', action=argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left them as private attributes of the module, but if there's really demand, we could rename them to argparse.StoreTrueAction, etc.
I like the strings. They are simple and easy to use/read and they don't have to be created or imported before the parser is defined. That allows me to put the parser setup right after the 'if __name__ == '__main__':' so it's easy to find and read. It also allows me to not import or create objects that may be expensive in either time or resources if I'm not going to use them. Also the strings help separate the parser from the rest of your program in a much cleaner way. This can make your programs more modular and easier to modify and maintain. Ron
On Mon, Mar 8, 2010 at 9:17 AM, Ron Adam <rrr@ronadam.com> wrote:
I like the strings. They are simple and easy to use/read and they don't have to be created or imported before the parser is defined.
I like them too. I don't see anything unpythonic about them.
That allows me to put the parser setup right after the 'if __name__ == '__main__':' so it's easy to find and read. It also allows me to not import or create objects that may be expensive in either time or resources if I'm not going to use them.
Also the strings help separate the parser from the rest of your program in a much cleaner way. This can make your programs more modular and easier to modify and maintain.
Also in this particular case a typo in the string will be caught just about at the same time as a typo in the name would be caught. -- --Guido van Rossum (python.org/~guido)
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard <steven.bethard@gmail.com> wrote:
In argparse, unlike optparse, actions are actually defined by objects with a particular API, and the string is just a shorthand for referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left them as private attributes of the module, but if there's really demand, we could rename them to argparse.StoreTrueAction, etc.
Any reason not to do something like: from argparse import actions ... parser.add_argument('--plot', actions.store_true) Basically a small namespace for the constants. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek
On Monday 08 March 2010, David Stanek wrote:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
<steven.bethard@gmail.com> wrote:
In argparse, unlike optparse, actions are actually defined by objects with a particular API, and the string is just a shorthand for referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left them as private attributes of the module, but if there's really demand, we could rename them to argparse.StoreTrueAction, etc.
Any reason not to do something like:
from argparse import actions ... parser.add_argument('--plot', actions.store_true)
Basically a small namespace for the constants. +1
On 8 Mar 2010, at 16:53 , David Stanek wrote:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard <steven.bethard@gmail.com> wrote:
In argparse, unlike optparse, actions are actually defined by objects with a particular API, and the string is just a shorthand for referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left them as private attributes of the module, but if there's really demand, we could rename them to argparse.StoreTrueAction, etc.
Any reason not to do something like:
from argparse import actions ... parser.add_argument('--plot', actions.store_true)
Basically a small namespace for the constants.
action is taken from **kwargs, not from a positional argument as *args is a sequence of option strings (so you can write add_argument('-p', '/p', '--plot', '--land-mass')). So you'd have to write add_argument('--plot', action=actions.store_true) which is straight from the department of redundant redundancies. An option would be parser.add(actions.StoreTrue('--plot')) but I'm not sure this makes any sense API-wise, and it would probably make the code a lot messier as the parser would have to reach into the action to get the information it needs. Either that, or the action would be an *arg and argparse would have to walk all of its *args type-testing each one to find if there's an action anywhere.
On Mon, Mar 8, 2010 at 11:49 AM, Xavier Morel <python-dev@masklinn.net> wrote:
On 8 Mar 2010, at 16:53 , David Stanek wrote:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard <steven.bethard@gmail.com> wrote:
In argparse, unlike optparse, actions are actually defined by objects with a particular API, and the string is just a shorthand for referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left them as private attributes of the module, but if there's really demand, we could rename them to argparse.StoreTrueAction, etc.
Any reason not to do something like:
from argparse import actions ... parser.add_argument('--plot', actions.store_true)
Basically a small namespace for the constants.
action is taken from **kwargs, not from a positional argument as *args is a sequence of option strings (so you can write add_argument('-p', '/p', '--plot', '--land-mass')). So you'd have to write add_argument('--plot', action=actions.store_true) which is straight from the department of redundant redundancies.
An option would be
parser.add(actions.StoreTrue('--plot'))
but I'm not sure this makes any sense API-wise, and it would probably make the code a lot messier as the parser would have to reach into the action to get the information it needs. Either that, or the action would be an *arg and argparse would have to walk all of its *args type-testing each one to find if there's an action anywhere.
You could just change my example to: from argparse.actions import store_true ... parser.add_argument('--plot', action=store_true) I would probably still import the actions namespace directly, but wouldn't have to. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek
Xavier Morel wrote:
So you'd have to write add_argument('--plot', action=actions.store_true) which is straight from the department of redundant redundancies.
This could easily be fixed with from argparse.actions import store_true
An option would be
parser.add(actions.StoreTrue('--plot'))
but I'm not sure this makes any sense API-wise, and it would probably make the code a lot messier as the parser would have to reach into the action to get the information it needs.
It would make more sense if the object concerned were called an Option or some such instead of an Action: parser.add(options.Bool('--plot')) -- Greg
Greg Ewing wrote:
Xavier Morel wrote:
So you'd have to write add_argument('--plot', action=actions.store_true) which is straight from the department of redundant redundancies.
This could easily be fixed with
from argparse.actions import store_true
Converting argparse from a module to a package (which would be necessary to make the above work) is above the bar I set for "easy". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
David Stanek <dstanek@dstanek.com> writes:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard <steven.bethard@gmail.com> wrote:
parser.add_argument ('--plot', action='store_true') […]
+1.
Any reason not to do something like:
from argparse import actions ... parser.add_argument('--plot', actions.store_true)
Basically a small namespace for the constants.
-1. That ignores the value to the programmer in specifying keyword arguments (there are a lot of arguments to the function, making keyword arguments a better mean-what-you-say choice). To be equivalent, it would have to be: from argparse import actions # ... parser.add_argument('--plot', action=actions.store_true) I prefer the string values. -- \ “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 Stallman, 2002 | Ben Finney
Greg Ewing wrote:
Steven Bethard wrote:
Because the names are so long and you'd have to import them, I've left them as private attributes of the module, but if there's really demand, we could rename them to argparse.StoreTrueAction, etc.
What's wrong with just StoreTrue?
All of this discussion about the class names is ignoring the main benefit of using the string names: - with Python variables, you just get a generic name error at the reference site (which may or may not be useful, depending on the program structure) - with a string, the parser *tells* you that the problem is with the requested action for a particular argument The second, explicit error is going to be more informative in most cases. Using strings also reduces the verbosity of the code, avoiding either an "argparse." buried in the middle of the function call, or else a "from argparse import <whatever>". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan wrote:
Greg Ewing wrote:
Steven Bethard wrote:
Because the names are so long and you'd have to import them, I've left them as private attributes of the module, but if there's really demand, we could rename them to argparse.StoreTrueAction, etc. What's wrong with just StoreTrue?
All of this discussion about the class names is ignoring the main benefit of using the string names:
- with Python variables, you just get a generic name error at the reference site (which may or may not be useful, depending on the program structure) - with a string, the parser *tells* you that the problem is with the requested action for a particular argument
The second, explicit error is going to be more informative in most cases.
Using strings also reduces the verbosity of the code, avoiding either an "argparse." buried in the middle of the function call, or else a "from argparse import <whatever>".
I agree that it should be left as a string. About the only reason I would suggest changing it from a string to an object is that it makes it obvious that argparse does accept an object that conforms to the Action API. But this is already well documented, so I don't see the need. Just leave it as a string. -- Eric.
On Wed, Mar 10, 2010 at 7:46 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
All of this discussion about the class names is ignoring the main benefit of using the string names:
Another benefit of strings is that data-driven argparse configuration will usually be slightly simpler. Some of us find things like that useful. :-) -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Fri, Mar 5, 2010 at 10:51 AM, Neal Becker <ndbecker2@gmail.com> wrote:
I generally enjoy argparse, but one thing I find rather ugly and unpythonic.
parser.add_argument ('--plot', action='store_true')
Specifying the argument 'action' as a string is IMO ugly.
If it really bothers you, you can use: action=argparse._StoreTrueAction instead. Undocumented (purposefully) but that's all argparse is doing under the covers. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
Le Fri, 05 Mar 2010 13:51:15 -0500, Neal Becker <ndbecker2@gmail.com> a écrit :
I generally enjoy argparse, but one thing I find rather ugly and unpythonic.
parser.add_argument ('--plot', action='store_true')
I would argue that a string is actually more Pythonic than integers or anonymous objects repurposed as magic constants. (I'm looking at things such as SEEK_SET and friends)
Antoine Pitrou wrote:
I would argue that a string is actually more Pythonic than integers or anonymous objects repurposed as magic constants. (I'm looking at things such as SEEK_SET and friends)
Strings are certainly preferable to ints, one reason being that they display as something meaningful in debugging output. But it also doesn't hurt to export named constants for them, in the interests of catching typos. -- Greg
Am 06.03.2010 03:28, schrieb Antoine Pitrou:
Le Fri, 05 Mar 2010 13:51:15 -0500, Neal Becker <ndbecker2@gmail.com> a écrit :
I generally enjoy argparse, but one thing I find rather ugly and unpythonic.
parser.add_argument ('--plot', action='store_true')
I would argue that a string is actually more Pythonic than integers or anonymous objects repurposed as magic constants. (I'm looking at things such as SEEK_SET and friends)
Me too. In absence of a separate symbol type, Python itself uses strings for this purpose (hence the intern()ing business). Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Neal Becker wrote:
I generally enjoy argparse, but one thing I find rather ugly and unpythonic.
parser.add_argument ('--plot', action='store_true')
Specifying the argument 'action' as a string is IMO ugly.
It isn't ideal, but having to grab constants from the module isn't ideal either. Using a string here allows argparse (and optparse before it) to spit out an explicit "unknown action" message. Using named constants a typo would just get you a generic NameError instead. With variable names only being checked at runtime, you wouldn't get the static name checking that is the primary benefit of using named constants in less dynamic languages. So, agreed that using strings isn't pretty, but there aren't any great alternatives available. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
I don't believe argparse's action specification scheme is bad either, but On 6 Mar 2010, at 13:50 , Nick Coghlan wrote:
you wouldn't get the static name checking that is the primary benefit of using named constants in less dynamic languages.
There are quite a few tools which do handle static checking of that kind of stuff, so while Python itself doesn't provide it (as a builtin) it's not like you can't get it some other way.
participants (17)
-
Antoine Pitrou -
Ben Finney -
Brian Curtin -
David Stanek -
Eric Smith -
Fred Drake -
Georg Brandl -
Greg Ewing -
Guido van Rossum -
Mark Russell -
Neal Becker -
Nick Coghlan -
R. David Murray -
Robert Kern -
Ron Adam -
Steven Bethard -
Xavier Morel