This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author andybuckley
Recipients andybuckley, kbriggs, loewis
Date 2009-02-26.13:42:01
SpamBayes Score 2.7714282e-08
Marked as misclassified No
Message-id <1235655724.75.0.151870925467.issue4278@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2009-02-26 13:42:05andybuckleysetrecipients: + andybuckley, loewis, kbriggs
2009-02-26 13:42:04andybuckleysetmessageid: <1235655724.75.0.151870925467.issue4278@psf.upfronthosting.co.za>
2009-02-26 13:42:03andybuckleylinkissue4278 messages
2009-02-26 13:42:01andybuckleycreate