[issue40253] Fix .py(w) file association with Pyhon 3 Windows installer

2020-04-12 Thread Eryk Sun


Eryk Sun  added the comment:

> I understand that py.exe is at least in part used to make handling 
> multiple python versions easier. 

On the command line the launcher supports multiple installed versions via the 
"-X[.Y][-32|-64]" option. In scripts it supports multiple versions via virtual 
shebangs, e.g. "#!python3.8-32". But shebangs can also use fully-qualified 
Windows paths, which allows directly running a script in a particular virtual 
environment, e.g. "#!C:\VEnv\SparkEnv\Scripts\python.exe". Without the 
launcher, the .py file association is locked on a single Python installation.

> I don't find py.exe. Should it be installed besides python.exe? 
> If not, where else? 

If installed for all users, the py launcher is in the Windows directory. 
Otherwise it's in the user's local application data in the directory 
"%LocalAppData%\Programs\Python\Launcher".

Try repairing the installation to ensure the py launcher is installed, 
preferably for all users if you have admin access.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40253] Fix .py(w) file association with Pyhon 3 Windows installer

2020-04-12 Thread virtualnobi

virtualnobi  added the comment:

Eryk, I installed from python.org (didn't even know that it would be available 
from Microsoft Store). 

Nevertheless, I don't find py.exe. Should it be installed besides python.exe? 
If not, where else? 

I understand that py.exe is at least in part used to make handling multiple 
python versions easier. As I planned to only have one version (which might have 
been a bad idea in hindsight :-(  I might have unchecked any option that 
sounded like this... 

Danke & Grüße von nobi

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40253] Fix .py(w) file association with Pyhon 3 Windows installer

2020-04-11 Thread Eryk Sun


Eryk Sun  added the comment:

> How do I get to the "rocket" launcher? 

The py.exe launcher is installed by default with the Python 3 distribution from 
python.org. Did you install that, or did you install the app distribution from 
the Microsoft Store?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40253] Fix .py(w) file association with Pyhon 3 Windows installer

2020-04-11 Thread virtualnobi

virtualnobi  added the comment:

Eryk - thanks for your response. 

> I recommend selecting the installed "Python.File" progid instead. 
> It's the "Python" app with the launcher icon that has a rocket on it.

I don't have a Python with rocket launcher. When I use "Open With" on Windows 
Explorer, I only have two Python icons with the yin-yan snakes, one with white 
background (I presume that's still 2.7, as the  file icons were white before), 
and one with black background (which is available since I installed 3.8). If I 
select "Choose default program" (or similar - I have a German Windows), the 
list still only contains these two Python icons, and lot of unrelated stuff 
(zip, thunderbird, etc.). Initially, the black-background Python was not in 
this list at all, and I continued by "Further Options" and used the resulting 
browser to pick the 3.8 version. Since then, I have white and black Pythons. 

How do I get to the "rocket" launcher? 

Danke & Grüße von nobi

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40253] Fix .py(w) file association with Pyhon 3 Windows installer

2020-04-11 Thread Eryk Sun


Eryk Sun  added the comment:

An "Applications\python.exe" progid gets created by browsing for "python.exe" 
when configuring the file association. For example, it gets created by the 
Windows shell (Explorer) via "open with" -> "choose another app" -> "look for 
another app on this PC". The shell has no option in this case to indicate that 
the filetype is a script that needs command-line arguments via "%*", so the 
"shell\open\command" template that it assigns is incorrect.

If the user also selects to "always use this app", the shell sets a 
"UserChoice" key in a key named for the file extension under 
"HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts". The user 
choice overrides the default association computed via HKCR settings. 
Applications are not supposed to meddle with the "UserChoice" key. Its contents 
are doubly protected by the key's security and a hash value.

The shell key for the file extension usually has two other subkeys: 
"OpenWithList" and "OpenWithProgids". These can also override the HKCR file 
association. The "OpenWithList" key lists executables that have been used to 
open the filetype via the "open with" menu, and it also contains an "MRUList" 
value that sorts the list by order of most recently used. The "OpenWithProgids" 
key caches progids that are used to open the program. Usually there's just one 
cached progid. But if there's more than one, in my experience the shell selects 
the progid that's associated with the first exectuable in the "OpenWithList", 
by order of the "MRUList" value. In this particular and peculiar case, the 
current file association follows whichever program was most recently selected 
in the "open with" list.

> I found this report which fixed the problem: 
> https://stackoverflow.com/questions/15281951

Continuing to use the shell-generated "Applications\python.exe" progid means 
that you won't have shebang support provided by the py.exe launcher (e.g. for 
associating scripts with particular virtual environments), the "Edit with IDLE" 
menu, or the shell-extension drop handler. 

I recommend selecting the installed "Python.File" progid instead. It's the 
"Python" app with the launcher icon that has a rocket on it. If you use the 
"open with" menu to select this progid, also select the option to always use 
the selected app. This sets the shell's "UserChoice" key to lock down the file 
association.

FYI, never modify the HKCR merged view as suggested by the linked SO answer. 
Modify the source hive in "HKCU\Software\Classes" or "HKLM\Software\Classes". 
If you modify HKCR directly, the key(s) that you end up modifying could be in 
one or the other hive depending on what's already present (e.g. you could 
modify a value just for the current user, though your intent is to modify it 
for all users). You should know whether you need to modify system settings, 
user settings, or both. If you don't know, you need to do more research before 
proceeding.

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40253] Fix .py(w) file association with Pyhon 3 Windows installer

2020-04-11 Thread virtualnobi

New submission from virtualnobi :

Recently installed Python 3.8 (from 2.7) on Windows 10, and all my scripts 
didn't work anymore. For some strange reason 

> python -s script.py args

would put the args into sys.argv[], while

> script.py args

would only show the script in sys.argv[]. I found this report which fixed the 
problem: 

https://stackoverflow.com/questions/15281951/sys-argv-contents-when-calling-python-script-implicitly-on-windows

(Basically, the .py(w) association in the registry need an additional '%*' 
parameter to pass the script parameters.)

So I assume the Python 3 Windows installer overwrote my earlier registry 
associations. 

The other way the problem happened could be that the Python 3 installer did not 
change the registry assocation to 3.8, and I did this manually. I verified that 
setting a "default program" for windows will put the deficient association 
(without argument passing) into the registry. 

Either way, I would expect that after installing Python 3.8, my scripts would 
really run with 3.8, and with their arguments. :-) 

Danke & Grüße von 
nobi

--
components: Installation, Windows
messages: 366192
nosy: paul.moore, steve.dower, tim.golden, virtualnobi, zach.ware
priority: normal
severity: normal
status: open
title: Fix .py(w) file association with Pyhon 3 Windows installer
type: behavior
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com