[getopt-sig] Recent changes in Optik

Tim Peters tim.one@comcast.net
Mon, 18 Feb 2002 19:07:37 -0500


[Greg Ward]
> ...
> If you don't supply a type and one is needed, Optik uses "string"; if
> you don't supply a destination and one is needed, Optik extracts a
> destination from your first long option, or your first short option
> if none is supplied.
>
> For example, the following is now valid:
>
>   parser = OptionParser()
>   parser.add_option("-f", "--file")

+1

> ...
> The downside of this is that it enables programmers to be implicit
> rather than explicit, and we all know that explicit is better than
> implicit.

    parser.add_option("-f", "--file", dest="file")

isn't so much explict as pointlessly redundant.  "Implicit" would be
"options named 'file', or, more generally, starting with 'fi', are probably
names of files, so by default those will be stored as string values; otoh,
options with names starting with 'i' or 'n', or named 'count' or starting
with 'count', are probably integers, so by default get stored as integer
attributes, and unless integer conversion fails, in which case ...".

> Personally, I will probably take advantage of the default
> type a lot, but not the default destination.  YMMV.

So will yours <wink>:  I bet you start using the default destination a lot
too.  Having an option with a different name than the name the option's
value is stored under is a common cause of strange logic errors due to
confusion, so it's a Postive Good to let the default destination rule force
best practice.

Good show!