[Python-Dev] 3.2.1 encoding surprise

[Vinay Sajip]

Glenn Linderman <v+python <at> 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
>           HKEY_CURRENT_USER\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