PEP proposal optparse

[James Nicolson]

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 <prologic at 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 <jlnicolson at gmail.com> 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:
>>
>>     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"
>