On 7/20/2011 7:19 AM, Vinay Sajip wrote:

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

    Since I don't yet have associations set up that point at the
    launcher, I thought I'd play with saying "py" in front of the
    command.

Why don't you have any associations pointing to the launcher? Did you delete
them? If you uninstall and install the launcher, are they present?

This is a followon from the other day... the launcher installer had placed launcher associations in HCU, which are not visible from ftype and assoc commands... so I deleted those, which returned my system to not having launcher associations, but Python 3.2.1 associations instead (they were, and remained, in HLM throughout the install, but HCU temporarily overrode them in some circumstances).

So the launcher is installed in c:\windows\system32, but doesn't have associations. Thought I'd play with it from the command line, before reinstalling with ALLUSERS=1 (or establishing the associations by hand).

It is still my opinion that the installer should ask whether it should be installed for all users or not, but from what you said the other day, this may be beyond the .msi installer.

    So I have a command foo.py using Python 3 syntax in a directory on
    my PATH.  It works fine, since Python 3.2.1 is in Python.file. 
    foo.py does not have a #! line.
    I can successfully execute:  foo.py
    However, the following fails:  py foo.py
    It fails, because foo.py is not found.  Instead, I have to specify:
    py d:\path\to\foo.py
    This is annoying, py should walk the PATH for unqualified files (the
    Windows PATH implicitly includes the current directory, of course,

It's not py's job to walk the path: the shell does that when you just type
"foo". It locates foo.py, and then invokes py because of file association - py
then checks the file for a shebang to decide which Python to dispatch it to.

Certainly when the launcher is invoked via an association, this would be the case. However, when the launcher is invoked via the command line, then the unqualified name is passed through. To be useful from the command line, the launcher should walk the PATH to find the .py file.

    OK, with that mystery solved, and using Notepad running as
    administrator to actually, successfully edit the file, it still runs
    the wrong version of Python.  Here is the content of the file, what

I'm afraid I can't reproduce this. When I invoke a script with the default
py.ini, py runs it with Python 2. When I add a [defaults]python=3 entry, py 
correctly runs it with Python 3.

I still get the same behavior. Is there any debugging output produced by py.exe that would tell what py.ini it looks in, and what the content is? What diagnostic steps might I take to produce additional information that would help you (or me, along the way) analyze the issue? I do not presently have a C compiler installed on this machine, however, unless it came along for a ride with something else.

    is wrong?  And why is the spacing around the = in the [commands]
    section so inconsistent?

That's just test data, not a real "production" py.ini. I was testing out
something, which is why the spaces around = are every which way, and I never got
around to changing it. More importantly, those customised commands, while
perhaps useful for testing, are useless in everyday Python usage: perhaps -O,
-Werror, -E, -S etc. might be more useful. I'll take suggestions as to what
might be useful customised commands to ship as a default.

Fine. I realize the launcher is still Beta. This was just a curiosity question.

Regards,

Vinay Sajip