The new launcher's "/usr/bin/env" virtual command searches PATH for the given command name, even if the command is "python" or "python3". The old launcher reserves these names.

If the command isn't found in PATH, the launcher ignores the shebang and runs the script normally. In this case, the GUI launcher, "pyw.exe", will execute the script using the default GUI binary (e.g. "pythonw.exe" from a registered installation).

Instead, a console window pops up and disappears instantly.

The launcher probably found the app execution alias "%LocalAppData%\Microsoft\WindowsApps\python3.exe". If the app version of Python 3 isn't installed, then by default Windows creates "python.exe" and "python3.exe" aliases for an "app installer" app that opens the store to install Python 3. If this app is passed any command-line arguments, it prints an informative message¹ and exits. Since the app installer doesn't inherit a console from "pyw.exe", it allocates one to print the message. This console window gets destroyed as soon as the app exits².

If you don't have the app distribution of Python installed, I recommend disabling the "python.exe" and "python3.exe" app execution aliases.

On double-clicking hello.pyw, a console opens, then the message box appears.

For the virtual command "/usr/bin/env python", the launcher searches PATH for "python.exe". Normally this binary is a console application, which means that the system automatically allocates a console for the process if it doesn't inherit one from the parent process.

The old launcher reserves names that start with "python", even for the "/usr/bin/env" virtual command. In this case, "pyw.exe" runs a registered version of the GUI (non-console) binary, "pythonw.exe".

Thank you for the explanation. So then it's a feature, not a bug, that my programs don't start after updating to 3.11 and I have to dive somewhere into the depths of the Windows configuration?

I would probably do that, but I can't expect my non-technical audience to do that, with the best will in the world.

If this isn't fixed, I'll have to modify my setup scripts to remove the "shebang" in Windows.

For now, I'll go back to Python 3.9 and continue to advise against version 3.11.

So then it's a feature, not a bug, that my programs don't start after updating to 3.11 and I have to dive somewhere into the depths of the Windows configuration?

Yes, it's a feature, but one that's not currently implemented to be novice friendly considering the default configuration of Windows. It would be nice if the launcher detected and ignored the "python.exe" and "python3.exe" aliases for the app installer. I don't recall if the API has something to simplify this, but even if it doesn't, the launcher could just read the data in the reparse point to check whether the target app is "Microsoft.DesktopAppInstaller". If it finds the app installer, ignore the shebang and run the default Python.

I'll have to modify my setup scripts to remove the "shebang" in Windows.

Can you use "/usr/bin/python3" instead of "/usr/bin/env python3"? The former is restricted to registered installations and commands. It does not search PATH for "python3.exe".

Can you use "/usr/bin/python3" instead of "/usr/bin/env python3"?

Thank you for the advice. Unfortunately, I can't test it for now, since I just uninstalled Python 3.11.1, just as I did some weeks ago with 3.11, that already cost me a lot of time until I even found the source of the problem at the "shebang".

Yes, it's a feature, but one that's not currently implemented to be novice friendly considering the default configuration of Windows.

I guess that's true. However, "novice" does not quite fit the non-tech user group of my open source software. I don't expect them to learn Python or anything. I want to provide them with useful applications that will work without problems even after they might switch to Linux some day. However, for many of them it may already be a hurdle that they have to install a Python interpreter for this at all.

Can you use "/usr/bin/python3" instead of "/usr/bin/env python3"?

This seems to do the trick. I have patched 24 projects so far. Thank you so much for your support.

However, I give consideration to the fact that there might be a zillion Python scripts out there that suddenly "stop working" after updating to 3.11 because of the shebang. Not a good prospect.

there might be a zillion Python scripts out there that suddenly "stop working" after updating to 3.11 because of the shebang.

I agree. I'd prefer for the launcher to ignore the result of searching PATH if it finds an app execution alias for "Microsoft.DesktopAppInstaller". I think it's the responsibility of the launcher to work around this common problem.

As to launching a GUI script with an attached console, that's not a showstopper, but it's also not correct behavior. The GUI script launcher could special case "python[X[.Y]]" to search for "pythonw[X[.Y]]". For your case, this would also avoid the pitfall of finding a "Microsoft.DesktopAppInstaller" alias. Windows doesn't create app installer aliases for "pythonw.exe" and "pythonw3.exe".

More generally, the GUI script launcher could always use the process creation flag DETACHED_PROCESS. This prevents the system from automatically allocating a console. Also, if the console script launcher is executed without a console, it should use the DETACHED_PROCESS flag when executing the command.

If a console application is launched that really requires a console, the spawned process may silently fail. A properly designed interpreter shouldn't crash if it has no console, but a script might die on an unhandled exception if it expects sys.std* to never be None, or if it expects to be able to open "CONIN$" or "CONOUT$" or use the console API. That would be peculiar behavior for a ".pyw" script, but not surprising for a ".py" script.

Can you use "/usr/bin/python3" instead of "/usr/bin/env python3"?

This a problem if you distribute your script to Mac users. This will use the default Python 3.9 install instead of any up-to-date installed versions. I believe BSDs have their python executables in /usr/local/bin/ as well. Because of the Windows Store version of Python and the stubs in the PATH there is no good way to distribute a script that runs cross-platform since the correct way is with the #!/usr/bin/env python3 shebang. It works on effectively every operating system except Windows without the py launcher and Windows 10/11 with py launcher.

A project I've worked on had no issues with just directing people to install the py launcher until the Windows Store version came around and broke things. Telling literally ever individual user to disable the app execution alias is draining on support volunteers. They're going to go with the alternate shebang right now but breaking BSD support and limiting the ability to use new language features is not ideal, and those are only the known issues. They're hoping this gets resolved before the problems end up as larger issues, but it doesn't really seem like this is actively trying to be resolved.