I’ve just installed 3.14 on my Windows machine, using that new Installer. While everything was OK before (3.13 and all versions before that), something is odd with the launcher.
arguments passed to .py-Files on command line are not passed on to the script itself
the script launches in its own console window
same for .pyw-files, which did not receive any arguments as well
Simple test for me was (written into a.py):
import sys
print(sys.argv)
input()
and running it should have yielded:
C:\Users\Myusername\Desktop>a.py test
['C:\\Users\\Myusername\\Desktop\\a.py', 'test']
Instead, it was opened in a new window with no 'test’ passed to the script.
I’ve re-installed 3.14 with the new installer/launcher a few times, to no avail.
Now, having reverted to the old installer, all is fine.
Is this normal? Has anyone else experienced that? Is there anything I could do?
a.py was exactly that 3-liner above (many of my scripts stopped working all of a sudden, and this was the quickest way to verify).
calling stuff with like py a.py test and python a.py test have worked before, parameters were passed there, I believe python3.14 is just an alias for the above; not sure about the new-window-issue, and the shebang-issue I experienced with .pyw files stayed that way too.
Unfortunately I had to remove the new installer/launcher and revert to , as I need my scripts working on this machine, so I cannot test anything else at the moment…
It all seems like whatever is bound do handle .py/.pyw files in Windows seems to be faulty, all links (that is, a .py file referenced in .lnks) and calling them directly is completely off. The shebang-issue may have been my bad (I’ve used those forever without understanding them properly), so I have removed them from all my scripts. The running-in-another-window-issue is just annoying, and indicates to me that the launcher is instantiating its own console, which is weird given it has worked before…
Yes, I mean the Install Manager (the one on the button) with “new”. The Standalone-Installer is the one we used to know (scheduled for removal with Py 3.16)
I appreciate the fact the binary is signed, and I appreciate the effort made to play nice with Windows, I appreciated I could see its capabilities, and that I was consulted first, before adding entries to %PATH% etc.
But I have to say, I really really do not like how when I invoke the new py from the command line (version 25.2.240.0), a separate window is created (that resembles the original internet application security warning I dismissed when I installed it). It is rapidly automatically closed which is great. But the fact it is opened at all for a CLI script is still annoying.
I couldn’t could reproduce Hr.SBU’s described behaviour though (Windows 11):
First cmd Window:
C:\Users\...\Python>a.py test
I clicked to open it with “Python (default)”, “Just this once”
Quite right - you’re way ahead of me. I’ve edited it now. If nobody confirms this is intended behaviour before the end of today, I’d gather the details and report it as a bug.
I also appreciate that it is easy to uninstall. But when I install a Python with it, and uninstall Python Install Manager (possible user error admittedly), the stranded Python cannot easily be uninstalled from the “Installed Apps” menu (the new version of the old “Add and Remove Programs menu”). When trying to do so, I get a pop up window with:
OK. Even if it’s bugs, I have no clue how/where to raise them, or even find someone to confirm them or even ask about them (probably not in the cpython repo?) :-/
According to PEP 773 / File Associations, the launcher should be associated properly with .py / .pyw and even hide the console; so, my guess would be, it’s broken…
I’d either raise an issue on the Github (check there’s not a special sub repo for the launcher) with all the details to reproduce it, and let the maintainers do as they see fit. Or park it until the back end of this week (give them chance to clear their desks after the Christmas break), then ping Steve and the team.
