3.7.5.  Any py script that I run with python.exe or py.exe executes just fine.  But if I try to run any py script with pythonW.exe or pyW.exe it will not run.  

I don't know where the logging for the python executable is located.

On the same machine, java.exe and javaW.exe work properly. (jar file runs exactly the same with either executable.  Only the cmd/console window is suppressed with "w" exe.



I am trying to isolate whether or not python 3.7.5 is to blame or this new windows 10 x64 1809 LTSC machine is to blame.

I have tested in both python 3.7.5 x86 and x64 versions.  the "W" console version does not run any py scripts.

On my previous laptop (win 8.1 x64) and (win2012 r2 x64 server, no problems) with 3.7.4 32 bit.

---

How do I have multiple MINOR versions of python together?  e.g. 3.7.3, 3.7.4, 3.7.5?  Can they be placed in separate folders?

by the way, just to be sure, I am actually running the python.exe / py.exe / pythonw.exe / pyw.exe from the full file path just to be sure.  e.g.

%LOCALAPPDATA%\Programs\Python\Launcher\pyw.exe  test.py

I installed v3.7.4 x86 and scripts work with `pythonw.exe` and `pyw.exe`

I also tested v3.7.4 x64 bit and scripts also work ok.  So that is some good news.

This proves that pythonw (python console) for 3.7.5 is not working for some unknown reasons.

It is not related to Win10 (thankfully, as that would be an entirely different beast)

Will revert to 3.7.4 and stick with it until further notice.

---

That's about 7 hours of my life I will not get back, but I hope it will help someone.

Can you give an example of a script that fails? If you try to print (or otherwise use the standard IO streams) pythonw will fail, because there are no stdio streams for a GUI executable - and the traceback, which goes to stderr by default, will be lost.

This is my best guess as to your issue here, but without a reproducible example, it's hard to say anything useful.

@paul.moore  all scripts failed.  it's like pyw.exe does not run at all (or quits shortly after.  i have about 5 proprietary scripts.

going back to 3.7.4 everything works as before.   I do suspect there is something wrong with the way that 3.7.5 was compiled for pythonW.exe


 python/pw.exe works fine for both 3.7.4 and 3.7.5 (x86 and x64 versions)
pythonW/pyW.exe works fine for 3.7.4 but not 3.7.5 (x86 and x64 versions)

This is the first time i've ever had this issue.  python 3.6.x.

I originally thought it was a win10 issue because I am setting up a new computer and using 3.7.5 for the first time.  (other computer had 3.7.4).

I will ask my programmer to give some sample code.  But really any existing script you have should work for testing 3.7.5 pythonw.exe , particularly if it requires a couple of non-core modules to run.

Let me know if you are unable to reproduce it.

> Let me know if you are unable to reproduce it.

x64 pythonw.exe and pyw.exe (3.7.5, 2019-10-14) work for me in Windows 10.0.18362. I have them installed for all users, respectively in "C:\Program Files\Python37" and "C:\Windows". 

Try running `pythonw.exe -m idlelib` and `pythonw.exe -m turtle`. If nothing runs, try it with python.exe, just to make sure tcl/tk and IDLE are installed.

> How do I have multiple MINOR versions of python together? 
> e.g. 3.7.3, 3.7.4, 3.7.5?  Can they be placed in separate 
> folders?

The standard distribution supports one major-version installation for the system and another per user. You can use the nuget packages to test against multiple minor versions.

https://docs.python.org/3/using/windows.html#the-nuget-org-packages

It seems that nuget packages can also be installed via PowerShell 6. However, the "Version" parameter of Visual Studio's Install-Package changes to "RequiredVersion" in PowerShell 6.

@eryk.  Could I just have separate folder with each python minor version?  I would keep it portable and just reference the python/pythonw.exe filepath directly for each version when I run.

I could just download the 3.7.5 and drop it anywhere.

BTW, I have win10 x64 v 1809 b 17763.720.

Can you try installing https://aka.ms/vs/16/release/VC_redist.x64.exe and then see if it makes a difference?

At least one package in 3.8 still contained a dependency on the C++ runtime, which we do not include, and it's possible that 3.7.5 had the same issue. Both will be fixed in the next updates, but the workaround is to install the file above.

When I have some time.  Maybe this weekend.  3.7.4 is working ok right now for production level.  So I didn't bother with anything else yet.

Might help someone else in the meantime though.  Glad to see that someone is taking the complaint seriously :)

> At least one package in 3.8 still contained a dependency on the C++ 
> runtime

FWIW, the very first thing that I checked was the dependencies of pythonw.exe, in case maybe I had a dependent DLL that's not distributed with Windows. There's nothing out of the ordinary:

    C:\Program Files\Python37>sigcheck -nobanner pythonw.exe
    C:\Program Files\Python37\pythonw.exe:
            Verified:       Signed
            Signing date:   7:12 PM 10/14/2019
            Publisher:      Python Software Foundation
            Company:        Python Software Foundation
            Description:    Python
            Product:        Python
            Prod version:   3.7.5
            File version:   3.7.5
            MachineType:    64-bit

    C:\Program Files\Python37>dumpbin /nologo /dependents pythonw.exe

    Dump of file pythonw.exe

    File Type: EXECUTABLE IMAGE

      Image has the following dependencies:

        python37.dll
        VCRUNTIME140.dll
        api-ms-win-crt-runtime-l1-1-0.dll
        api-ms-win-crt-math-l1-1-0.dll
        api-ms-win-crt-stdio-l1-1-0.dll
        api-ms-win-crt-locale-l1-1-0.dll
        api-ms-win-crt-heap-l1-1-0.dll
        KERNEL32.dll

      Summary

            1000 .data
            1000 .pdata
            1000 .rdata
            1000 .reloc
           14000 .rsrc
            2000 .text

For me, 'pyw -3.7 -m idlelib' in Command Prompt opens IDLE with 3.7.5.  So does the equivalent run by clicking the IDLE icon:
C:\Programs\Python37\pythonw.exe "C:\Programs\Python37\Lib\idlelib\idle.pyw"

This report reminds me that I should continue to install and minimally test each release.

> FWIW, the very first thing that I checked was the dependencies of pythonw.exe

The version in the Store has a different build of pythonw.exe (because it has to be able to determine its user site-packages location differently).

Dump of file C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1520.0_x64__hd69rhyc2wevp\pythonw.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    api-ms-win-core-libraryloader-l1-2-0.dll
    api-ms-win-core-com-l1-1-0.dll
    api-ms-win-core-errorhandling-l1-1-0.dll
    SHELL32.dll
    python37.dll
    MSVCP140.dll  ****** bug here, but already fixed for next release
    VCRUNTIME140.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-core-handle-l1-1-0.dll
    api-ms-win-core-synch-l1-1-0.dll
    api-ms-win-core-rtlsupport-l1-1-0.dll
    api-ms-win-core-processthreads-l1-1-0.dll
    api-ms-win-core-processthreads-l1-1-1.dll
    api-ms-win-core-debug-l1-1-0.dll
    api-ms-win-core-profile-l1-1-0.dll
    api-ms-win-core-sysinfo-l1-1-0.dll
    api-ms-win-core-interlocked-l1-1-0.dll
    KERNEL32.dll
    api-ms-win-core-winrt-l1-1-0.dll
    api-ms-win-core-winrt-string-l1-1-0.dll
    OLEAUT32.dll
    api-ms-win-core-winrt-error-l1-1-1.dll
    api-ms-win-core-winrt-error-l1-1-0.dll

Assuming the fix for this was released, given lack of other information.