argparse missing optparse capabilities?

rurpy at rurpy at
Thu Jan 5 12:36:48 EST 2012

On 01/05/2012 02:19 AM, Ulrich Eckhardt wrote:
> Am 05.01.2012 09:05, schrieb rurpy at
>> I have optparse code that parses a command line containing
>> intermixed positional and optional arguments, where the optional
>> arguments set the context for the following positional arguments.
>> For example,
>> arg1 -c33 arg2 arg3 -c44 arg4
>> 'arg1' is processed in a default context, 'args2' and 'arg3' in
>> context '33', and 'arg4' in context '44'.
> Question: How would you e.g. pass the string "-c33" as first argument,
> i.e. to be parsed in the default context?

There will not be a need for that.

> The point is that you separate the parameters in a way that makes it
> possible to parse them in a way that works 100%, not just a way that
> works in 99% of all cases.

I agree that one should strive for a syntax that "works
100%" but in this case, the simplicity and intuitiveness
of the existing command syntax outweigh by far the need
for having it work in very improbable corner cases.
(And I'm sure I've seen this syntax used in other unix
command line tools in the past though I don't have time
to look for examples now.)

If argparse does not handle this syntax for some such
purity reason (as opposed to, for example. it is hard
to do in argparse's current design) then argparse is
mistakenly putting purity before practicality.

> For that reason, many commandline tools
> accept "--" as separator, so that "cp -- -r -x" will copy the file "-r"
> to the folder "-x". In that light, I would consider restructuring your
> commandline.

In my case that's not possible since I am replacing an
existing tool with a Python application and changing the
command line syntax is not an option.

>> I am trying to do the same using argparse but it appears to be
>> not doable in a documented way.
> As already hinted at, I don't think this is possible and that that is so
> by design.

Thanks for the confirmation.  I guess that shows that
optparse has a reason to exist beyond backwards compatibility.

More information about the Python-list mailing list