Re: [Python-Dev] argparse ugliness
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 | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
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 | ncogh...@gmail.com | Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Wed, Mar 10, 2010 at 7:46 AM, Nick Coghlan ncogh...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Mon, 08 Mar 2010 15:35:46 -0600, Robert Kern robert.k...@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():
http://code.google.com/p/argparse/issues/detail?id=62
Shouldn't argparse bugs/enhancement tickets be going to bugs.python.org
now?
--
R. David Murray www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Tue, Mar 9, 2010 at 11:31, R. David Murray rdmur...@bitdance.com wrote:
On Mon, 08 Mar 2010 15:35:46 -0600, Robert Kern robert.k...@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():
http://code.google.com/p/argparse/issues/detail?id=62
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum gu...@python.org wrote:
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker ndbeck...@gmail.com wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker ndbeck...@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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Mon, Mar 8, 2010 at 7:40 AM, Steven Bethard steven.beth...@gmail.com wrote:
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum gu...@python.org wrote:
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker ndbeck...@gmail.com wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker ndbeck...@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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
steven.beth...@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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Monday 08 March 2010, David Stanek wrote:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
steven.beth...@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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On 8 Mar 2010, at 16:53 , David Stanek wrote:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
steven.beth...@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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Mon, Mar 8, 2010 at 11:49 AM, Xavier Morel python-...@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.beth...@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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
Steven Bethard wrote:
On Mon, Mar 8, 2010 at 7:40 AM, Steven Bethard steven.beth...@gmail.com wrote:
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum gu...@python.org wrote:
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker ndbeck...@gmail.com wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker ndbeck...@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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Mon, Mar 8, 2010 at 9:17 AM, Ron Adam r...@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) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
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.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
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? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
David Stanek dsta...@dstanek.com writes:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
steven.beth...@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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
Am 06.03.2010 03:28, schrieb Antoine Pitrou:
Le Fri, 05 Mar 2010 13:51:15 -0500,
Neal Becker ndbeck...@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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker ndbeck...@gmail.com wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker ndbeck...@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)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] argparse ugliness
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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Fri, Mar 5, 2010 at 12:51, Neal Becker ndbeck...@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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Fri, Mar 5, 2010 at 10:51 AM, Neal Becker ndbeck...@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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
Le Fri, 05 Mar 2010 13:51:15 -0500,
Neal Becker ndbeck...@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)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
