[Python-Dev] 3.2.1 encoding surprise (original) (raw)

Vinay Sajip vinay_sajip at yahoo.co.uk
Tue Jul 19 03:41:16 CEST 2011

Glenn Linderman <v+python g.nevcal.com> writes:

So, then, there must be 2 problems... one in the launcher installer, and the other being whatever happened to my machine.

I think so. I know that Windows sometimes adds file type associations under HKCU which shadow the ones set up in HKLM, but I'm not sure why or how it happens.

Well, there is only one. But I can certainly remove it, and see what happens.

Okay, just making sure.

So what I had done was just double click launchsys.msi. Why should there be command line parameters, rather than question/answer dialogs? This is Windows after all. What does the parameter do, that would be different than what double click did?

Windows is unfortunately not consistent in its behaviour across different versions - if you Google for ALLUSERS you'll probably find the information that makes some people tear their hair out. So the ALLUSERS=1 forces Windows to install under HKLM ("for all users" as opposed to "just for me") and to fail if you don't have admin rights. Note that the ALLUSERS= is something introduced by Microsoft, not something launcher-specific.

I also still don't understand why CMD reports a different command line via its assoc/ftype commands for the Python.File than actually gets used by CMD to launch the .py file.

I believe it's to do with multiple versions in the registry.

something that makes our situation more complicated) is the fact that HKCR is in fact registry symlink and this registry key doesn’t really exists on system. It is merge of two different keys – HKLM\Software\Classes and HKCU\Software\Classes. You probably already guessed (correctly) that this is the way how you can overwrite some settings on per-user basis – HKCU key always wins.

which is useful, but still doesn't explain the variant results from ftype and launching behavior.} They further say: You need to create file type using FTYPE first and then associate this TFYPE with executable using ASSOC command. Even though this process is not very simple, you can use it. There is one HUGE disadvantage though and I still don’t understand how is it possible – both FTYPE and ASSOC works only on per-machine level! Therefore you cannot configure per-user associations using these tools!

I have certainly seen file type associations for .py in HKCU, whose presence there I can't explain, but it's probably wrongly created by some Windows software common in the ecosystem (if not Windows itself), which manifests in odd ways - search deadlybloodyserious.com for problems where command line arguments aren't passed to scripts because of bad ftype/assoc registry entries. I would advise not using ftype/assoc commands, as you certainly shouldn't need them for Python files if you install the launcher.

Currently, there is no way through the UI to change or edit the user-specific file type associations stored in the HKEYCURRENTUSER\SOFTWARE\Classes registry key. If you want to do this, you have to directly edit the registry or develop your own UI to gain access to this information.

Above you can see official Microsoft statement about this issue.

Yes, but some software in Windows (perhaps "select program from a list" or similar) definitely does set values in HKCU as a side-effect of doing something else, which comes back to bite you later. I have personally experienced the same problem as the blogger on deadlybloodyserious.com (which is how I came across the solution on that site - by Googling to see if anyone else had encountered it).

Clearly the launcher installer should offer the same choices as Python itself for installing for one or all users, rather than defaulting silently to one user. Better, the default should be inherited from the Python installation... if they are all consistent, and if permissions allow the modification of HLM settings.

Yes, but the launcher installer is beta software, and it's not yet clear exactly how the launcher will be packaged with Python 3.3. Clearly if packaged as an automatic installation with Python, it will use Python defaults.

Note that ALLUSERS was introduced precisely because Microsoft didn't think things through initially with sufficient care, and there's no way to get consistent behaviour across XP and Vista/Windows 7. It's possible to force ALLUSERS=1 in the .msi, but this means that non-admin users can't try the launcher. Unfortunately AFAICT, there's no obvious solution which "just works", though if someone were to point out a solution it could certainly be tried.

So I can fix my machine, now that I understand what went wrong (delete py.exe entries from HCU, and put them in HLM instead). Then the other problem I have, is why py.exe launched py 2.6.4 instead of py 3.2.1 when 3.2.1 is newer, and I don't have a #! line. That is probably the defined behavior of the launcher, to prefer 2.x if 3 isn't specified. I'll have to reread the launcher PEP. In my environment, I would much prefer to use 3.x if 2.x isn't specified... so hopefully when I reread the launcher PEP, I'll discover a way to do that. (I recall one can put -3 on the command line, so I could do that in the py.exe ftype commands, but hopefully there is a way to tweak the py.ini to do that.)

Yes, the PEP explains what you need to do to get Python 3 to be the default: use the py.ini file or use an environment variable.

The use of py from the command line is merely a convenience for developers (as the PEP says) - it's better to rely on shebang lines together with settings in the .ini to get the behaviour you want.

Regards,

Vinay Sajip

More information about the Python-Dev mailing list