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 <[EMAIL PROTECTED]>:
> 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 <[EMAIL PROTECTED]> 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"
>
--
http://mail.python.org/mailman/listinfo/python-list
