Hi,
I would like to know your thoughts on a proposed change to optparse
that I have planned. It is possible to add default values to multiple
options using the set_defaults. However, when adding descriptions to
options the developer has to specify it in each add_option() call.
This results in unreadable code such as:
parser.add_option('-q', '--quiet' , action="store_false",
dest='verbose',
help = 'Output less information')
parser.add_option('-o', '--output' , type='string',
dest='castordir' , metavar='<DIR>' ,
help = 'specify the wanted CASTOR directory where to store the
results tarball')
parser.add_option('-r', '--prevrel' , type='string',
dest='previousrel' , metavar='<DIR>' ,
help = 'Top level dir of previous release for regression
analysis' )
The same code could become much more readable if there was an
equivalent method of set_defaults for the description/help of the
option. The same code could then become:
parser.set_description(
verbose = 'Output less information',
castordir = 'specify the wanted CASTOR directory where
to store the results tarball',
previousrel = 'Top level dir of previous release for
regression analysis')
parser.add_option('-q', '--quiet' , action="store_false",
dest='verbose')
parser.add_option('-o', '--output' , type='string',
dest='castordir' , metavar='<DIR>' )
parser.add_option('-r', '--prevrel' , type='string',
dest='previousrel' , metavar='<DIR>' )
Help descriptions can often be quite long and separating them in this
fashion would, IMHO, be desirable.
Kind Regards,
James Nicolson 10 1392
Hi James,
I can't say I really agree with your
proposal. I tend to keep the help
descriptions of my options short
and concise and to the point.
Also, one must use the language's
features (indentation) to your advantage,
as doing so ensure readability.
For example (from my bhimport tool):
<snippet>
def parse_options():
"""parse_options() -opts, args
Parse any command-line options given returning both
the parsed options and arguments.
"""
parser = optparse.OptionParser(usage=USAGE, version=VERSION)
parser.add_option("", "--date-format",
action="store",type="str", default="%d/%m/%Y",
dest="dateFormat",
help="date format string")
parser.add_option("", "--time-format",
action="store", type="str", default="%H:%M:%S",
dest="timeFormat",
help="time format string")
parser.add_option("", "--datetime-format",
action="store", type="str", default="%H:%M:%S %d/%m/%Y",
dest="datetimeFormat",
help="datetime format string")
opts, args = parser.parse_args()
if len(args) < 2:
parser.print_help()
raise SystemExit, 1
return opts, args
</snippet>
As you can see (as long as you're
reading this in fixed-width fonts)
it _is_ very readable.
cheers
James
On 9/18/08, James <jl********@gmail.comwrote:
Hi,
I would like to know your thoughts on a proposed change to optparse
that I have planned. It is possible to add default values to multiple
options using the set_defaults. However, when adding descriptions to
options the developer has to specify it in each add_option() call.
This results in unreadable code such as:
parser.add_option('-q', '--quiet' , action="store_false",
dest='verbose',
help = 'Output less information')
parser.add_option('-o', '--output' , type='string',
dest='castordir' , metavar='<DIR>' ,
help = 'specify the wanted CASTOR directory where to store the
results tarball')
parser.add_option('-r', '--prevrel' , type='string',
dest='previousrel' , metavar='<DIR>' ,
help = 'Top level dir of previous release for regression
analysis' )
The same code could become much more readable if there was an
equivalent method of set_defaults for the description/help of the
option. The same code could then become:
parser.set_description(
verbose = 'Output less information',
castordir = 'specify the wanted CASTOR directory where
to store the results tarball',
previousrel = 'Top level dir of previous release for
regression analysis')
parser.add_option('-q', '--quiet' , action="store_false",
dest='verbose')
parser.add_option('-o', '--output' , type='string',
dest='castordir' , metavar='<DIR>' )
parser.add_option('-r', '--prevrel' , type='string',
dest='previousrel' , metavar='<DIR>' )
Help descriptions can often be quite long and separating them in this
fashion would, IMHO, be desirable.
Kind Regards,
James Nicolson
-- http://mail.python.org/mailman/listinfo/python-list
--
--
-- "Problems are solved by method"
Perhaps it is better to keep descriptions short and store longer
descriptions elsewhere, but there are many programs that have long
descriptions, for example try: ls --help (at least on my machine a lot
of these descriptions are quite long).
2008/9/18 James Mills <pr******@shortcircuit.net.au>:
Hi James,
I can't say I really agree with your
proposal. I tend to keep the help
descriptions of my options short
and concise and to the point.
Also, one must use the language's
features (indentation) to your advantage,
as doing so ensure readability.
For example (from my bhimport tool):
<snippet>
def parse_options():
"""parse_options() -opts, args
Parse any command-line options given returning both
the parsed options and arguments.
"""
parser = optparse.OptionParser(usage=USAGE, version=VERSION)
parser.add_option("", "--date-format",
action="store",type="str", default="%d/%m/%Y",
dest="dateFormat",
help="date format string")
parser.add_option("", "--time-format",
action="store", type="str", default="%H:%M:%S",
dest="timeFormat",
help="time format string")
parser.add_option("", "--datetime-format",
action="store", type="str", default="%H:%M:%S %d/%m/%Y",
dest="datetimeFormat",
help="datetime format string")
opts, args = parser.parse_args()
if len(args) < 2:
parser.print_help()
raise SystemExit, 1
return opts, args
</snippet>
As you can see (as long as you're
reading this in fixed-width fonts)
it _is_ very readable.
cheers
James
On 9/18/08, James <jl********@gmail.comwrote:
>Hi,
I would like to know your thoughts on a proposed change to optparse that I have planned. It is possible to add default values to multiple options using the set_defaults. However, when adding descriptions to options the developer has to specify it in each add_option() call. This results in unreadable code such as:
parser.add_option('-q', '--quiet' , action="store_false", dest='verbose', help = 'Output less information') parser.add_option('-o', '--output' , type='string', dest='castordir' , metavar='<DIR>' , help = 'specify the wanted CASTOR directory where to store the results tarball') parser.add_option('-r', '--prevrel' , type='string', dest='previousrel' , metavar='<DIR>' , help = 'Top level dir of previous release for regression analysis' )
The same code could become much more readable if there was an equivalent method of set_defaults for the description/help of the option. The same code could then become:
parser.set_description( verbose = 'Output less information', castordir = 'specify the wanted CASTOR directory where to store the results tarball', previousrel = 'Top level dir of previous release for regression analysis')
parser.add_option('-q', '--quiet' , action="store_false", dest='verbose') parser.add_option('-o', '--output' , type='string', dest='castordir' , metavar='<DIR>' ) parser.add_option('-r', '--prevrel' , type='string', dest='previousrel' , metavar='<DIR>' )
Help descriptions can often be quite long and separating them in this fashion would, IMHO, be desirable.
Kind Regards, James Nicolson
-- http://mail.python.org/mailman/listinfo/python-list
--
--
-- "Problems are solved by method"
James Mills wrote:
As you can see (as long as you're
reading this in fixed-width fonts)
it _is_ very readable.
given that it only relies on indentation from the left margin, it's no
less readable in a proportional font (unless you're using an font with
variable-width spaces, that is ;-).
</F>
On Thu, 18 Sep 2008 03:37:54 -0700, James wrote:
Hi,
I would like to know your thoughts on a proposed change to optparse that
I have planned. It is possible to add default values to multiple options
using the set_defaults. However, when adding descriptions to options the
developer has to specify it in each add_option() call. This results in
unreadable code such as:
[snip]
I don't find it unreadable at all. I find it very helpful to have the
help text associated right there with the rest of the option, instead of
hidden in a different function call.
[...]
Help descriptions can often be quite long and separating them in this
fashion would, IMHO, be desirable.
If the help descriptions are so long that they are a problem, then the
solution I would choose is to put them in their own module, then do
something like this:
import docs
parser.add_option('-q', '--quiet', action="store_false",
dest='verbose', help=docs.quiet)
parser.add_option('-o', '--output', type='string',
dest='castordir', metavar='<DIR>', help=docs.output)
etc.
--
Steven
While we're making suggestions, I've always wished that the
--help output displayed the default values for options in
addition to the help text specified by the user. I end up
having to enter the default values twice -- once as a keyword
argument and again in the help text. Then later when I decide
to change the default value, things get out-of-sync.
--
Grant Edwards grante Yow! Did you move a lot of
at KOREAN STEAK KNIVES this
visi.com trip, Dingy?
Grant Edwards wrote:
While we're making suggestions, I've always wished that the
--help output displayed the default values for options in
addition to the help text specified by the user. I end up
having to enter the default values twice -- once as a keyword
argument and again in the help text. Then later when I decide
to change the default value, things get out-of-sync.
Tangential to this thread, what's the preferred way to get
changes into optparse? Based on the comments I've read in the
optparse.py file, it looks like it's the generated output of some
other process. I've patched my local version to include some
changes for handling newlines in help text (which has cropped up
on the list occasionally, as the current version eats newlines),
but am not sure whether I need to be patching against the
optparse.py or against the file that generated it (which I don't
have in my install, AFAIK).
Perhaps one of the core devs that works on optparse could tell me
how they'd prefer such changes submitted?
Thanks,
-tkc
On Thu, 18 Sep 2008 11:07:45 -0500, Grant Edwards wrote:
While we're making suggestions, I've always wished that the --help
output displayed the default values for options in addition to the help
text specified by the user. I end up having to enter the default values
twice -- once as a keyword argument and again in the help text.
'%default' in the help text will be replaced by the default value. See
the last option in the first example here: http://docs.python.org/lib/optparse-...ting-help.html
Ciao,
Marc 'BlackJack' Rintsch
On 2008-09-18, Marc 'BlackJack' Rintsch <bj****@gmx.netwrote:
On Thu, 18 Sep 2008 11:07:45 -0500, Grant Edwards wrote:
>While we're making suggestions, I've always wished that the --help output displayed the default values for options in addition to the help text specified by the user. I end up having to enter the default values twice -- once as a keyword argument and again in the help text.
'%default' in the help text will be replaced by the default value. See
the last option in the first example here:
http://docs.python.org/lib/optparse-...ting-help.html
Great! I guess I should scan the doc pages for changes more
often.
--
Grant Edwards grante Yow! The Korean War must
at have been fun.
visi.com
On Thu, Sep 18, 2008 at 9:02 PM, James Nicolson <jl********@gmail.comwrote:
Perhaps it is better to keep descriptions short and store longer
descriptions elsewhere, but there are many programs that have long
descriptions, for example try: ls --help (at least on my machine a lot
of these descriptions are quite long).
The longer (program) description is generally
provided by the Usage help string. This
(in my tools) is generally a long-ish docstring
describing the tool, and it's usage.
cheers
James
--
--
-- "Problems are solved by method"
James <jl********@gmail.comwrites:
I would like to know your thoughts on a proposed change to optparse
that I have planned. It is possible to add default values to
multiple options using the set_defaults. However, when adding
descriptions to options the developer has to specify it in each
add_option() call.
-1
I see no advantage to swelling optparse when the language offers many
solutions already. E.g.
desc = {
'verbose': 'Output less information',
'castordir': 'specify the wanted CASTOR directory where to store '
'the results tarball',
'previousrel': 'Top level dir of previous release for regression '
'analysis'}
parser.add_option('-q', '--quiet', action="store_false",
dest='verbose', help = desc['verbose'])
....
Or another approach might be like this.
for ... in zip(...):
parser.add_option(...)
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent pe*********@westerngeco.com -./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Hans-Joachim Widmaier |
last post by:
I was really pleased when the Optik module found its way into the
standard Python battery compartment, as it matched all my option
parsing requirements. But, as always, there's really nothing that...
|
by: washu |
last post by:
Hi,
I'm was going through the module help located on
http://docs.python.org/lib/optparse-store-action.html and I tried
modifying it a tiny bit and things don't work. If someone could tell me...
|
by: Henry Ludemann |
last post by:
I've been writing an optparse alternative (using getopt) that is at a
stage where I'd be interested in people's opinions. It allows you to
easily creating command line interfaces to existing...
|
by: Karlo Lozovina |
last post by:
If I create a file with only one line:
---
from optparse import OptionParser
---
I get this when I try to run it from "DOS" prompt:
Traceback (most recent call last):
File "optparse.py",...
|
by: Bob |
last post by:
I'd like to setup command line switches that are dependent on other
switches, similar to what rpm does listed below. From the grammar below
we see that the "query-options" are dependent on the...
|
by: Steven Bethard |
last post by:
I feel like I must be reinventing the wheel here, so I figured I'd post
to see what other people have been doing for this. In general, I love
the optparse interface, but it doesn't do any checks...
|
by: Pupeno |
last post by:
Hello,
I am doing some extreme use of optparse, that is, extending it as explained
on
http://docs.python.org/lib/optparse-other-reasons-to-extend-optparse.html
I have subclassed OptionParser and...
|
by: mbeachy |
last post by:
Some rather unexpected behavior in the set_default/set_defaults
methods for OptionParser that I noticed recently:
<Option at 0x-483b3414: -r/--restart>
{'restart': None}
{'retart': False,...
|
by: Robert Kern |
last post by:
Jeff Keasler wrote:
If you code it up with unit tests and documentation, it has a good chance. But
in the meantime, you can tell optparse to stop processing options using the
standard "--"...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |