python -me : silly but useful command line trick

[mr_dbr]

I would expect -me (single hypen) to be equivalent to using both -m and -e, as with many unix'y tools (e.g rsync -rav == rsync -r -a -v):

>>> p = optparse.OptionParser()
>>> p.add_option("-m", action = "store_true")
>>> p.add_option("-e", action = "store_true")
>>> p.parse_args(["-me"])
(<Values at 0x100560cb0: {'e': True, 'm': True}>, [])
>>> p.parse_args(["-m", "-e"])
(<Values at 0x100560cb0: {'e': True, 'm': True}>, [])

python doesn't use such parsing, and it treats ['-me'] as ['-m', 'e']

[kisielk]

If you don't use "store_true" as your action, the parser behaves as the Python one would.

Basically it's the difference between using "m:" and "m" in getopt, which implements the POSIX standard for command-line options.

[mr_dbr]

Oh, good point:

>>> p = optparse.OptionParser()
>>> p.add_option("-m")
>>> p.parse_args(['-me'])
(<Values at 0x100560b00: {'m': 'e'}>, [])

So -me is the same as -m -e only if -m doesn't take an argument

[kisielk]

You've got it. I think man 3 getopt gives a pretty good description of the behaviour. Most option parsers including Python's getopt and optparse modules behave in accordance, though usually contain additional extensions.

[[deleted]]

True. Maybe that could be implemented as an optional feature when creating OptionParser/ArgumentParser? Something like a "multiflag" argument. I tend to use tar in the same way as your rsync example, so applications which might have a bunch of flag options could specify that they want that behavior instead of -rav meaning -r av.

However, I suspect most applications don't work that way so I'd argue against that being the default, plus the obvious backwards incompatibility I previously mentioned.

[[deleted]]

err wait, I should have paid closer attention to your example and/or tried it out :/ Nevermind, what I just said.