$ python --help
usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Options and arguments (and corresponding environment variables):
-B : don't write .py[co] files on import; also PYTHONDONTWRITEBYTECODE=x
-c cmd : program passed in as string (terminates option list)
-d : debug output from parser; also PYTHONDEBUG=x
-E : ignore PYTHON* environment variables (such as PYTHONPATH)
-h : print this help message and exit (also --help)
-i : inspect interactively after running script; forces a prompt even
if stdin does not appear to be a terminal; also PYTHONINSPECT=x
-m mod : run library module as a script (terminates option list)
-O : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x
-OO : remove doc-strings in addition to the -O optimizations
-R : use a pseudo-random salt to make hash() values of various types be
unpredictable between separate invocations of the interpreter, as
a defense against denial-of-service attacks
-Q arg : division options: -Qold (default), -Qwarn, -Qwarnall, -Qnew
-s : don't add user site directory to sys.path; also PYTHONNOUSERSITE
-S : don't imply 'import site' on initialization
-t : issue warnings about inconsistent tab usage (-tt: issue errors)
-u : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x
see man page for details on internal buffering relating to '-u'
-v : verbose (trace import statements); also PYTHONVERBOSE=x
can be supplied multiple times to increase verbosity
-V : print the Python version number and exit (also --version)
-W arg : warning control; arg is action:message:category:module:lineno
also PYTHONWARNINGS=arg
-x : skip first line of source, allowing use of non-Unix forms of #!cmd
-3 : warn about Python 3.x incompatibilities that 2to3 cannot trivially fix
file : program read from script file
- : program read from stdin (default; interactive mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup (no default)
PYTHONPATH : ':'-separated list of directories prefixed to the
default module search path. The result is sys.path.
PYTHONHOME : alternate <prefix> directory (or <prefix>:<exec_prefix>).
The default module search path uses <prefix>/pythonX.X.
PYTHONCASEOK : ignore case in 'import' statements (Windows).
PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.
PYTHONHASHSEED: if this variable is set to 'random', the effect is the same
as specifying the -R option: a random value is used to seed the hashes of
str, bytes and datetime objects. It can also be set to an integer
in the range [0,4294967295] to get hash values with a predictable seed.
python /path/to/the/script.py
One of the apps I was responsible for where I worked was written using FoxPro for DOS. I rewrote it using VFP. But, MS announced that they were dropping VFP and pushing VFP developers to .NET. I was hanging out at the UniversalThread's VFP forum, along with 225,000 other VFP developers. That announcement caused an uproar. I could see the hand writing on the wall and began looking around for another GUI RAD tool. I tried some Java tools but the speed issue and the verbosity turned me off. I tried Python, using Boa-Constructor, and almost went with it. But, at the levels and subroutines where I need to place some of my code were warning: "DO NOT EDIT THIS FILE, IT WILL BE REGENERATED AUTOMATICALLY AT COMPILE TIME AND YOUR CHANGES WILL BE OVERWRITTEN." So close, yet so far. I really loved Python though, and used it for some other applications related to bulletin board service the dept of revenue was running for tax consultants. I gave Qt3 a try but really disliked it, and for me KDevelop really stunk, but that was probably Qt3's fault. If you used Qt3-Designer you had to call subroutines and subprograms by setting drop-down combo boxes in Qt3-Designer. What a straight jacket. I was on the verge of dropping it when Qt4 came out. Qt4 returned to the time-tested traditional C++ development style. The Designer was only for designing windows and forms. I've stuck with Qt4 every since. For me, Kate, KDbg and Qt4 made an awesome combo!
One of the apps I was responsible for where I worked was written using FoxPro for DOS. I rewrote it using VFP. But, MS announced that they were dropping VFP and pushing VFP developers to .NET. I was hanging out at the UniversalThread's VFP forum, along with 225,000 other VFP developers. That announcement caused an uproar. I could see the hand writing on the wall and began looking around for another GUI RAD tool. I tried some Java tools but the speed issue and the verbosity turned me off. I tried Python, using Boa-Constructor, and almost went with it. But, at the levels and subroutines where I need to place some of my code were warning: "DO NOT EDIT THIS FILE, IT WILL BE REGENERATED AUTOMATICALLY AT COMPILE TIME AND YOUR CHANGES WILL BE OVERWRITTEN." So close, yet so far. I really loved Python though, and used it for some other applications related to bulletin board service the dept of revenue was running for tax consultants. I gave Qt3 a try but really disliked it, and for me KDevelop really stunk, but that was probably Qt3's fault. If you used Qt3-Designer you had to call subroutines and subprograms by setting drop-down combo boxes in Qt3-Designer. What a straight jacket. I was on the verge of dropping it when Qt4 came out. Qt4 returned to the time-tested traditional C++ development style. The Designer was only for designing windows and forms. I've stuck with Qt4 every since. For me, Kate, KDbg and Qt4 made an awesome combo!
Comment