.pyw and pythonw does not run under Windows 7

后端 未结 7 1389
猫巷女王i
猫巷女王i 2020-12-13 19:46

Running a simple .py or .pyw python file causes python.exe to show up under Task Manager.

python myApp.py
python myApp.pyw

How

相关标签:
7条回答
  • 2020-12-13 19:53

    Try adding the line import sys; sys.stderr = open("errlog.txt", "w") to the start of myApp.py. Then look in errlog.txt for a traceback or any other error messages.

    0 讨论(0)
  • 2020-12-13 19:57

    Im not sure I understand your problem but I think this is what you need to know

    you need to right click on a py or pyw file and select open with ... find python.exe (probably C:\Python27\python.exe) .. check the box that says always open ... now you can just double click it if you want to run it

    (usually the installer sets this up for you ...)

    0 讨论(0)
  • 2020-12-13 19:57

    This is an old answer, but I want to leave my solution here also:

    • Open CMD (with elevated privileges or not - depends on your needs)
    • Change to directory of .py / .pyw script - this is important
    • Run pythonw with script as argument

      cd E:\my\script\folder\
      pythonw script.py
      
    0 讨论(0)
  • 2020-12-13 20:00

    tl;dr

    • To troubleshoot, use output redirection on invocation:

      pythonw myApp.py 1>stdout.txt 2>stderr.txt
      

    This will capture stdout output, such as from print(), in file stdout.txt, and stderr output (such as from unhandled exceptions), in file stderr.txt; from PowerShell, use
    cmd /c pythonw myApp.py 1>stdout.txt 2>stderr.txt).
    Note that the very act of redirecting stdout may actually make your script work again, if the only reason for its failure with pythonw was the use of print (in Python 2.x - see below).
    Caveat: This output redirection technique seemingly does not work when invoking *.pyw scripts directly (as opposed to by passing the script file path to pythonw.exe). Do let me know if you know why and/or if it does work for you.

    • To fix your script:

    Place the following at the top of any Python 2.x or 3.x script that you want to run with pythonw.exe:

    import sys, os
    if sys.executable.endswith("pythonw.exe"):
      sys.stdout = open(os.devnull, "w");
      sys.stderr = open(os.path.join(os.getenv("TEMP"), "stderr-"+os.path.basename(sys.argv[0])), "w")
    

    This ensures the following when a script is run with pythonw.exe:

    • print() calls and explicit calls to sys.stdout() are effectively ignored (are no-ops).
    • Stderr output, including from an unhandled fatal exception, is sent to file %TEMP%\stderr-<scriptFileName>; %TEMP% is a standard Windows environment variable that points to the current user's folder for temporary files.

    In other words: With the above code in place, check file %TEMP%\stderr-<scriptFileName> after your script has failed silently when invoked with pythonw.exe.

    For an explanation, read on.


    On Windows, pythonw.exe is for launching GUI/no-UI-at-all scripts, which means that the standard in- and output streams - sys.stdin, sys.stdout, sys.stderr are NOT available.

    This has two nasty side effects:

    • Using print() - which targets sys.stdout by default - causes an exception in Python 2.x.
      • This problem has been fixed in Python 3.x.
    • Any unhandled exception - including one triggered by print() in 2.x - causes the script to abort silently.
      • Exception error messages go to sys.stderr by default, which is the very thing not available in this scenario.

    The above code fixes these problems by:

    • sending stdout output to the null device, effectively ignoring any attempt to output to sys.stdout - whether explicitly, or implicitly via print().

    • sending all stderr output to a temporary file.


    Differences between Python 2.x and Python 3.x:

    When a script is run with pythonw.exe, sys.stdin, sys.stdout, and sys.stderr:

    • in Python 2.x: have invalid file descriptors
      • The eventual result when trying to write to sys.stdout or sys.stderr is the following exception: IOError: [Errno 9] Bad file descriptor
      • Pitfall: Due to output buffering, this exception may not surface until you've output, say, 4K bytes; you can provoke it instantly by invoking pythonw.exe with -u (for unbuffered output).
      • print() blindly tries to sys.stdout (by default), so it provokes this exception sooner or later.
    • in Python 3.x: are set to None
      • This is complemented with the 3.x print() function performing a no-op (doing nothing) when it finds that sys.stdout is None, so that print() statements can by default safely be used - they'll simply be ignored when run with pythonw.exe
      • However, it follows that trying to use sys.stdout.write() and sys.stderr.write() still results in an exception.

    See here for more background.

    0 讨论(0)
  • 2020-12-13 20:04

    I faced the same problem on a script of my own and found that when adding the output from Ross' answer the script would actually run.

    It appears that for some reason that redirecting output fixes the problem. Since I'm not interested in writing the output to disk I've instead written it to /dev/null (or the platform equivalent) with:

    if ( sys.platform == 'win32' and sys.executable.split( '\\' )[-1] == 'pythonw.exe'):
        sys.stdout = open(os.devnull, 'w')
        sys.stderr = open(os.devnull, 'w')
    

    The if statement ensures it only happens when the script is launched from pythonw.exe. I'm not sure if it is related but it was important to do this before other imports (including e.g. import logging).

    0 讨论(0)
  • 2020-12-13 20:14

    I had a similar problem after an upgrade to my computer RAM. Turns out I had to reinstall Pillow (library used for image processing). So make sure it is installed and if it's not, install it using "pip install Pillow" in cmd.

    0 讨论(0)
提交回复
热议问题