Hi,

Check the following code:

--------------opttest.py----------
from optparse import OptionParser

def process_options():
    global options, args, parser
    parser = OptionParser()

    parser.add_option("--test", action="store_true")
    parser.add_option("-m", metavar="COMMENT", dest="comment", default=None)
    (options, args) = parser.parse_args()
    return

process_options()

print "comment (%r)" % options.comment
---------------------

$ ./opttest.py -m --test
comment ('--test')

I was expecting this to give an error as "--test" is an option. But it looks like even C library's getopt() behaves similarly. It will be nice if optparse can report error in this case. 

I am attaching the code fragment as a file since the indentation got all messed up in the original post. 
File Added: opttest.py

I think what you're asking for is ambiguous at best.  In your example, how could optparse possibly decide that the "--test" is a second option, not an option argument?  What if you *do* want "--test" as an argument?

Assigning to Greg Ward. Recommend closing as invalid.

It is possible to deduce "--test" as an option because it is in the list of options given to optparse. But your point about what if the user really wants "--test" as an option argument is valid. I guess this request can be closed. 

Thanks,
Raghu.

For what it's worth, argparse_ gives an error here:

>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('--test', action='store_true')
>>> parser.add_argument('-m', dest='comment')
>>> parser.parse_args(['-m', '--test'])
usage: PROG [-h] [--test] [-m COMMENT]
PROG: error: argument -m: expected one argument

That's because argparse assumes that anything that looks like "--foo" is an option (unless it's after the pseudo-argument "--" on the command line).

.. _argparse: http://argparse.python-hosting.com/

So how does one give option arguments starting with - to argparse?

At the moment, you generally can't:
    http://argparse.python-hosting.com/ticket/25
though the simple value "-" is valid. I do plan to address this in the not-so-distant future (though no one yet has complained about it).

For optparse module, I think the OP's problem could likely be fixed by editing _process_long_opt() and _process_short_opts() to do some checks around the code:

    elif nargs == 1:
        value = rargs.pop(0)
    else:
        value = tuple(rargs[0:nargs])
        del rargs[0:nargs]

You could make sure that the option arguments (the "value" objects in the code above) were not already existing options with a check like:

    all(not self._match_long_opt(arg) and
        not self._short_opt.get(arg)
        for arg in rargs[0:nargs])

Closing since optik is maintained separately.  Please file a feature request at http://sourceforge.net/projects/optik