Long story short: pythonw.exe does nothing, python.exe accepts nothing (which one should I use?)
test.py:
print "a" CMD window:
C:\path>pythonw.exe test.py <BLANK LINE> C:\path> C:\path>python.exe test.py File "C:\path\test.py", line 7 print "a" ^ SyntaxError: invalid syntax C:\path> Please tell me what I'm doing terrible wrong.
To summarize and complement the existing answers:
python.exe is a console (terminal) application for launching CLI-type scripts (console applications).
Unless run from an existing console window, python.exe opens a new console window.
Standard streams sys.stdin, sys.stdout and sys.stderr are connected to the console window.
Execution is synchronous when launched from a cmd.exe or PowerShell console window: See eryksun's 1st comment below.
pythonw.exe is a GUI app for launching GUI/no-UI-at-all scripts.
sys.stdin, sys.stdout and sys.stderr are NOT available. print() can cause that to happen (in 3.x, print() simply has no effect). pythonw.exe yourScript.pyw 1>stdout.txt 2>stderr.txtcmd /c pythonw.exe yourScript.pyw 1>stdout.txt 2>stderr.txt) to capture stdout and stderr output in files.print() is the only reason your script fails silently with pythonw.exe, and you're not interested in stdout output, use @handle's command from the comments:pythonw.exe yourScript.pyw 1>NUL 2>&1*.pyw scripts directly (as opposed to by passing the script file path to pythonw.exe). See eryksun's 2nd comment and its follow-ups below.You can control which of the executables runs your script by default - such as when opened from Explorer - by choosing the right filename extension:
*.py files are by default associated (invoked) with python.exe*.pyw files are by default associated (invoked) with pythonw.exe
> pythonw ls.pyw >nul 2>&1 (even though nothing is written).
start command. It actually inspects the PEB of the child process to determine whether it's a console process. The console host process (conhost.exe) doesn't care about this. If you use subprocess.Popen to attach another python.exe instance to the current console and don't wait on it, then you'll have a confusing mess of both processes racing to access the console simultaneously.NtCreateUserProcess. If the target executable is a console program, the system unconditionally inherits the parent's standard handles. But for a non-console program it requires being explicitly told to inherit the parent's inheritable handles. To run a file based on a file association, cmd calls ShellExecuteEx, which does not explicitly inherit handles when it calls CreateProcess => NtCreateUserProcess. Consequently redirecting standard I/O works in cmd when starting console .py scripts but not non-console .pyw scripts.CreateProcess with bInheritHandles passed as TRUE. It only falls back on ShellExecuteEx when CreateProcess fails because the target isn't a PE executable (e.g. it's a .py script) or requires elevation (e.g. osk.exe). So when you directly run pythonw.exe or pyw.exe, it will inherit cmd's StandardInput, StandardOutput, and StandardError, which cmd (actually the CRT) modifies via SetStdHandle before and after calling CreateProcess when standard I/O is redirected to a pipe, file, or device.STARTUPINFO handles (hStdInput, hStdOutput, hStdErr), unlike Python's subprocess.Popen. It can get away with this because it's a single-threaded program. It's only due to this design that redirection works at all with ShellExecuteEx (just for console programs, as noted) because the GUI shell API otherwise has no support for standard I/O.If you don't want a terminal window to pop up when you run your program, use pythonw.exe;
Otherwise, use python.exe
Regarding the syntax error: print is now a function in 3.x
So use instead:
print("a") See here: http://docs.python.org/using/windows.html
pythonw.exe "This suppresses the terminal window on startup."
pythonw.exe has side effects that your program may fail silenty if it writes to stdout/stderr stream - see bugs.python.org/issue706263If you're going to call a python script from some other process (say, from the command line), use pythonw.exe. Otherwise, your user will continuously see a cmd window launching the python process. It'll still run your script just the same, but it won't intrude on the user experience.
An example might be sending an email; python.exe will pop up a CLI window, send the email, then close the window. It'll appear as a quick flash, and can be considered somewhat annoying. pythonw.exe avoids this, but still sends the email.
python.exe will not open another one.I was struggling to get this to work for a while. Once you change the extension to .pyw, make sure that you open properties of the file and direct the "open with" path to pythonw.exe.
