python -me : silly but useful command line trick
voidspace.org.uk/python/weblog/arch_d7_2010_1...Posted Dec 29, 2010, 5:15 PM UTC
4417
voidspace.org.uk
Pyeval is even better.
3
The way these options work sounds wrong. What if I define an option titled "me". What takes precedence? Python shouldn't allow this. Is it optparse/argparse default behavior?
1
-m is a flag for the Python executable, and it executes the e module. Define all the me options you want -- the options you specify for your script are for your script only.
Think of -h help options. The Python executable has one and many scripts often have one as well. Neither of them interfere with the other.
3
Let me rephrase the question:
If I define an option "-m" in optparse, will the command line:
myscript.py -me
cause the "m" flag to receive "e" as it's value? If so, this sounds wrong. If this isn't the case in optparse or argparse, I don't think the python executable should behave any differently.
-1
Your m option would receive e as its value unless it was truly considered a "flag", e.g., True if present, False if not.
-me is no different than -m e, which is the case for any option parser I've encountered.
2
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']
2
Ok, I just tested optparse and it does behave like you say. Does this seem reasonable in your eyes?
1
Cygwin python: /usr/bin/python: No module named e
Similar trouble on Windows Py 2.6 2.7 3.1
0
Nevermind. This is not a standard module...
2
pip install e
5
Python, I love you just a little bit more.