Message82753
Are these really bugs? The first message just reports the error the
other way around from how you view it: you are thinking of "-TO" as a
two-character "short option", optparse thinks of it as a two-character
long option which is missing a dash. I would side with optparse's
definition, since the point of short options is that they can be
combined under a single dash --- a multi-character option can't do that,
and so can't be "short" by definition.
In both this and the "-h" issue, optparse is reasonably enforcing a UI
convention as well as providing parsing facilities. That uniformity of
UI behaviour is a design goal is made explicit in the documentation.
Using optparse means that users can rely on "-h" to give them help
documentation, which IMO is a very useful convention to respect. And the
splitting of long and short options by whether they are single character
(and hence can be combined) or multi-character (hence uncombinable, but
good for less-used options without eating up the alphabetic option
namespace) is another nice convention which optparse enforces.
-1 from me: I think the existing behaviours are good, largely *because*
they aren't flexible. |
|
Date |
User |
Action |
Args |
2009-02-26 13:42:05 | andybuckley | set | recipients:
+ andybuckley, loewis, kbriggs |
2009-02-26 13:42:04 | andybuckley | set | messageid: <1235655724.75.0.151870925467.issue4278@psf.upfronthosting.co.za> |
2009-02-26 13:42:03 | andybuckley | link | issue4278 messages |
2009-02-26 13:42:01 | andybuckley | create | |
|