[Python-Dev] 3.2.1 encoding surprise

[Glenn Linderman]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110720/20678bc3/attachment.html>