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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com