Attached reduced test case works fine with Python 3.1, fails with Python3.2: SyntaxError: Non-ASCII character '\xc3' in file D:\my\py\t32enc.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details I'm familiar with the PEP, but thought 3.x cured that. Python 3.1 produces no error; I'm not sure that 3.2 did or didn't report such problems, or if the programs I ran with 3.2 simply didn't contain non-ASCII characters. The file is UTF-8 encoded with no pseudo-BOM. Is this intentional, or a regression (in which case I will open a ticket)? If a regression, does that mean we have no tests for it, possibly because most of the tests contain the PEP 263 encoding directive, because most people using 3.x are still also using 2.x (I am not)?
On 7/18/2011 3:10 PM, Glenn Linderman wrote:
Attached reduced test case works fine with Python 3.1, fails with Python3.2:
SyntaxError: Non-ASCII character '\xc3' in file D:\my\py\t32enc.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
It runs fine for me on winxp, 3.2.1, both command prompt and idle. When cut/paste worked, I downloaded file and ran that.
I'm familiar with the PEP, but thought 3.x cured that. Python 3.1 produces no error; I'm not sure that 3.2 did or didn't report such problems, or if the programs I ran with 3.2 simply didn't contain non-ASCII characters.
The file is UTF-8 encoded with no pseudo-BOM.
Is this intentional, or a regression (in which case I will open a ticket)?
If a regression, does that mean we have no tests for it, possibly because most of the tests contain the PEP 263 encoding directive, because most people using 3.x are still also using 2.x (I am not)?
Or there could be a test (have not checked) which usually passes. -- Terry Jan Reedy
2011/7/18 Glenn Linderman <v+python@g.nevcal.com>:
Attached reduced test case works fine with Python 3.1, fails with Python3.2:
PS D:\Data> py -3 .\t32enc.py PS D:\Data> py -2 .\t32enc.py File ".\t32enc.py", line 1 SyntaxError: Non-ASCII character '\xc3' in file .\t32enc.py on line 1, but no encoding declared; see http://www.python.o rg/peps/pep-0263.html for details PS D:\Data> py -3 --version Python 3.2.1 PS D:\Data> py -2 --version Python 2.7 Windows 7 32-bit, py is Vinay's implementation of the PEP 397 launcher for Windows. This looks like correct output to me. Could it be your environment somehow? Paul.
Similar outcome as Paul's. $ python3 t32enc.py $ python t32enc.py File "t32enc.py", line 1 SyntaxError: Non-ASCII character '\xc3' in file t32enc.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details $ python3 -V Python 3.2.1a0 $ python -V Python 2.6.1 Running the script on OSX 10.6.8 (And I just realised I am running 3.2.1a0...) Cheers On Tue, Jul 19, 2011 at 6:01 AM, Paul Moore <p.f.moore@gmail.com> wrote:
2011/7/18 Glenn Linderman <v+python@g.nevcal.com>:
Attached reduced test case works fine with Python 3.1, fails with Python3.2:
PS D:\Data> py -3 .\t32enc.py PS D:\Data> py -2 .\t32enc.py File ".\t32enc.py", line 1 SyntaxError: Non-ASCII character '\xc3' in file .\t32enc.py on line 1, but no encoding declared; see http://www.python.o rg/peps/pep-0263.html for details PS D:\Data> py -3 --version Python 3.2.1 PS D:\Data> py -2 --version Python 2.7
Windows 7 32-bit, py is Vinay's implementation of the PEP 397 launcher for Windows.
This looks like correct output to me.
Could it be your environment somehow? Paul. _______________________________________________ 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/anthony.hw.kong%40gmail.co...
-- Tony Kong *blog:* www.ahwkong.com Don’t EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That’s giving your intelligence *much* too much credit. - Linus Torvalds
On 7/18/2011 1:01 PM, Paul Moore wrote:
2011/7/18 Glenn Linderman<v+python@g.nevcal.com>:
Attached reduced test case works fine with Python 3.1, fails with Python3.2: PS D:\Data> py -3 .\t32enc.py PS D:\Data> py -2 .\t32enc.py File ".\t32enc.py", line 1 SyntaxError: Non-ASCII character '\xc3' in file .\t32enc.py on line 1, but no encoding declared; see http://www.python.o rg/peps/pep-0263.html for details PS D:\Data> py -3 --version Python 3.2.1 PS D:\Data> py -2 --version Python 2.7
Windows 7 32-bit, py is Vinay's implementation of the PEP 397 launcher for Windows.
This looks like correct output to me.
Could it be your environment somehow? Paul.
Yes, a surprise. But it is my environment.... I'm not sure exactly how or why yet. I've continued investigating since posting that... but thanks for the confirmation that it isn't 3.2.1 ! Tweaked the program to show the version and it showed 2.6.4! Which is the only version of Python 2.x installed here. So my suspicion is that launchsys.adm64.msi, installed just after 3.2.1 (but which appeared to do nothing) has taken over ... something. Not sure what yet. The reason I thought it did nothing, is that I checked assoc ( =Python.File ) and ftype ( =c:\python32\python.exe "%1" %* ) both of which look familiar, and neither of which mention py.exe which is what I think the launcher is supposed to have been named; and running c:\python32\python.exe from the command line produces a Python that looks like 3.2.1 . But somehow, running t32enc.py from the command line fails, and loads 2.6.4 ! From what I've read about the launcher, I thought it was supposed to take over the assoc and ftype and point Python.File to c:\windows\system32\py.exe -- but that hasn't happened (and yes, I've rebooted since doing the installs, so it is not just a leftover CMD that didn't pick up new values). So my question now is: how does the launcher really get activated when invoking .py files from the command line, if the assoc and ftype indicate that it should run c:\python32\python.exe (which when I run by hand, seems to be what the name claims it to be)? We don't need to create mysteries! Glenn
The reason I thought it did nothing, is that I checked assoc ( =Python.File ) and ftype ( =c:\python32\python.exe "%1" %* ) both of which look familiar, and neither of which mention py.exe which is what I think the launcher is supposed to have been named; and running c:\python32\python.exe from the command line produces a Python that looks like 3.2.1 . But somehow, running t32enc.py from the command line fails, and loads 2.6.4 ! From what I've read about the launcher, I thought it was supposed to take over the assoc and ftype and point Python.File to c:\windows\system32\py.exe -- but that hasn't happened (and yes, I've rebooted since doing the installs, so it is not just a leftover CMD that didn't pick up new values). So my question now is: how does the launcher really get activated when invoking .py files from the command line, if the assoc and ftype indicate that it should run c:\python32\python.exe (which when I run by hand, seems to be what the name claims it to be)? We don't need to create mysteries! Glenn
The launcher's activation is done by the shell you're using, which does the lookups in the registry. Remember that there are two sets of locations - HKCU and HKLM - where the type associations are potentially held. Please do a registry search (with Administrator rights so you can search the whole registry) for "py.exe" or "pyw.exe" and see if they show up anywhere at all. The launcher code tries to add these keys in HKEY_CLASSES_ROOT, but I believe Windows can map this to HKCU rather than HKLM if you don't have administrator access, at least on XP. Regards, Vinay Sajip
On 7/18/2011 2:13 PM, Vinay Sajip wrote:
Remember that there are two sets of locations - HKCU and HKLM - where the type associations are potentially held. Please do a registry search (with Administrator rights so you can search the whole registry) for "py.exe" or "pyw.exe" and see if they show up anywhere at all. The launcher code tries to add these keys in HKEY_CLASSES_ROOT, but I believe Windows can map this to HKCU rather than HKLM if you don't have administrator access, at least on XP.
Oh, and I'm running Windows 7 64-bit, but most of my registry knowledge was learned on Win2K and XP, and I have no knowledge of what they did in Vista or 7, and haven't yet attempted to research such. I am running as an administrator, but a much more ignorant one on 7 than I was on XP. I have no idea why CMD would show an ftype Python.File as one thing, but then the execution would use something from the registry that is different.
On 7/18/2011 2:13 PM, Vinay Sajip wrote:
The reason I thought it did nothing, is that I checked assoc ( =Python.File ) and ftype ( =c:\python32\python.exe "%1" %* ) both of which look familiar, and neither of which mention py.exe which is what I think the launcher is supposed to have been named; and running c:\python32\python.exe from the command line produces a Python that looks like 3.2.1 . But somehow, running t32enc.py from the command line fails, and loads 2.6.4 ! From what I've read about the launcher, I thought it was supposed to take over the assoc and ftype and point Python.File to c:\windows\system32\py.exe -- but that hasn't happened (and yes, I've rebooted since doing the installs, so it is not just a leftover CMD that didn't pick up new values). So my question now is: how does the launcher really get activated when invoking .py files from the command line, if the assoc and ftype indicate that it should run c:\python32\python.exe (which when I run by hand, seems to be what the name claims it to be)? We don't need to create mysteries! Glenn
The launcher's activation is done by the shell you're using, which does the lookups in the registry.
Remember that there are two sets of locations - HKCU and HKLM - where the type associations are potentially held. Please do a registry search (with Administrator rights so you can search the whole registry) for "py.exe" or "pyw.exe" and see if they show up anywhere at all. The launcher code tries to add these keys in HKEY_CLASSES_ROOT, but I believe Windows can map this to HKCU rather than HKLM if you don't have administrator access, at least on XP.
Thanks for the response, Vinay... you are the one that would know, now that I've figured out it is a launcher issue rather than a Python issue. Here is a list of py.exe references in my registry: HCR\Python.CompiledFile HCR\Python.File HCR\Python.NoConFile HCU\Software\Classes\Python.CompiledFile HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\OpenWithListk HLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21.....\Componer HLM\SOFTWARE\Wow6432Note\Microsoft\Windows\CurrentVersion\SharedDLLs HKU\S-1-5-21-.....\Software\Classes\Python.CompiledFile (and similar corresponding to the above HCR ones) My (perhaps dated) understanding of the CMD commands attrib and ftype is that they reflect the contents of HCR. But here HCR\Python.File is different than the value displayed by the CMD ftype Python.File. Why? What am I missing?
Glenn Linderman <v+python <at> g.nevcal.com> writes:
Here is a list of py.exe references in my registry: HCR\Python.CompiledFile HCR\Python.File HCR\Python.NoConFile
[snip] There shouldn't be so many references, so I suggest you may want to try the following (after backing up your registry first): 1. Uninstall all instances of the launcher. 2. Remove all registry keys for .py, .pyc, .pyo, .pyw, Python.File, Python.NoConFile, and Python.CompiledFile. 3. Re-install the launcher (64-bit) using "msiexec /i launchsys.amd64.msi ALLUSERS=1" (or launcher.amd64.msi if you prefer - the only difference is the installation directory). 4. Check that the removed associations have appeared under HKEY_LOCAL_MACHINE, and that they all point to the launcher installed in the previous step. These may also appear in HKEY_CLASSES_ROOT if it is aliased to the HKEY_LOCAL_MACHINE\Software\Classes tree. Regards, Vinay Sajip
On 7/18/2011 4:55 PM, Vinay Sajip wrote:
Glenn Linderman<v+python<at> g.nevcal.com> writes:
Here is a list of py.exe references in my registry: HCR\Python.CompiledFile HCR\Python.File HCR\Python.NoConFile
[snip]
There shouldn't be so many references, so I suggest you may want to try the following (after backing up your registry first):
So, then, there must be 2 problems... one in the launcher installer, and the other being whatever happened to my machine. Can you list the ones there should be?
1. Uninstall all instances of the launcher.
Well, there is only one. But I can certainly remove it, and see what happens.
2. Remove all registry keys for .py, .pyc, .pyo, .pyw, Python.File, Python.NoConFile, and Python.CompiledFile. Yes, I can do this.
3. Re-install the launcher (64-bit) using "msiexec /i launchsys.amd64.msi ALLUSERS=1" (or launcher.amd64.msi if you prefer - the only difference is the installation directory). 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? 4. Check that the removed associations have appeared under HKEY_LOCAL_MACHINE, and that they all point to the launcher installed in the previous step. These may also appear in HKEY_CLASSES_ROOT if it is aliased to the HKEY_LOCAL_MACHINE\Software\Classes tree.
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. Found the following at http://zetconsultants.com/blog/?p=36:
Second issue (not really an issue, however 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!
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 <http://support.microsoft.com/kb/257592/en-us> about this issue.
So maybe the problem is that ftype and assoc report the HLM values, but CMD actually uses the HCU values. This actually would explain what I am seeing, and this is the piece of information I didn't understand that caused my confusion. So as long as everything is installed for "all users", then there is no confusion! I see I have less than 3 dozen extensions installed in HCU, and over 800 in HLM, so clearly I choose "all users" most of the time. It would be painstaking to see if the 3 dozen were all consistent or not, without writing a program to help. 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.
Regards,
Vinay Sajip
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.) Thanks for your response, and help in creating the launcher.
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
On 7/18/2011 6:41 PM, Vinay Sajip wrote:
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.
Sure, and that's why I'm trying it out now, to provide feedback. But because I couldn't tell from assoc and ftype commands that it had done anything, I was a bit surprised by the behaviors I did encounter when I encountered them. So now I've learned about the limits of ftype and assoc, sadly. And they only work for setting things in HLM if you "Run as administrator", by the way. Wonder if there is a third party command line tool which augments them for reading/setting HCU Classes? Will search. I know there is a command line registry tool somewhere, but specifying the paths correctly would be onerous. Would be nice if the default of Py 2.x or 3.x were an install question, perhaps. I know that only affects scripts without #! lines, but it would be nice to limit the required creation of those to the smaller class of preexisting scripts on a particular installation.
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.
Could be, with .msi and/or .cab installers. I have no knowledge of them, except that when I first needed to use an installer to package things, I read a bit about them, and determined that they are too complex for my brain. I found NSIS, still complex, but it is much friendlier to my brain, but it seems to handle this case correctly, giving the installer creator the option of asking for or demanding elevation, and exposing the answer to the rest of the logic of the installer, so it can do different things for those cases if it desires.
On 7/18/2011 7:03 PM, Glenn Linderman wrote:
Wonder if there is a third party command line tool which augments them for reading/setting HCU Classes? Will search. I know there is a command line registry tool somewhere, but specifying the paths correctly would be onerous.
XP+ has REG and REGINI commands which can manipulate the registry from the command line, without resorting to third party applications. So a batch file could wrap them, to avoid mistyping keys, and one could make an FTYPE.CMD and ASSOC.CMD (I haven't, at least not yet). Also <http://vim.wikia.com/wiki/Windows_file_associations> although specific to Vim, is addressing the general problem, and comments by readers on that page seem relevant:
The following is a "for reader's information" comment; not a suggestion that the tip be changed. In classic Microsoft style, using HKEY_CLASSES_ROOT is ambiguous. I do not know the details, but on at least some systems (after Windows 9x), I think the following is correct:
HKEY_LOCAL_MACHINE\Software\Classes : for all users HKEY_CURRENT_USER\Software\Classes : for interactive user HKEY_CLASSES_ROOT : merged view of above (and is used by Win9x apps <http://vim.wikia.com/wiki/Windows_file_associations#>)
I don't know what happens if you write to HKEY_CLASSES_ROOT (which does not exist). Perhaps (like installing some apps), if you are in the Administrators group, you will write to HKLM, otherwise you will write to HKCU. JohnBeckett <http://vim.wikia.com/wiki/User:JohnBeckett> 08:24, 2 July 2009 (UTC)
------------------------------------------------------------------------
This is correct as far as I know. I wanted to include some information about how HKCR is a merged view of HKLM/Software/Classes and HKCU/Software/Classes, but doing so would beg information such as "what happens when I edit an entry that actually exists in HKCU?" etc. From experimentation, it seems that creating /new/ keys in this area will always create it in HKLM (system-wide), and ftype and assoc certainly do that, but I don't really have any documentation of that fact, and I don't know what it will do for limited-privilege accounts. I also don't know what happens when you edit an existing key, but I imagine it will "do the right thing" and keep the original where it was. I don't know this for a fact though. For these reasons, I left out that tidbit. But if we can answer some of these questions, it would be a good thing to include.
So attempts by applications to use the HKEY_CLASSES_ROOT directly may result in variant behavior depending on the privilege of the application. My overall opinion? It is sad that M$ even invented the registry.
On 7/18/2011 6:41 PM, Vinay Sajip wrote:
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.
OK, took a few minutes to play with the launcher again. I have removed the HCU classes that point at the launcher, leaving me with all my Python.File stuff pointing at some version of Python or another. I seem to have Python 2.6.4, Python 3.1, and Python 3.2.1 installed, all 64-bit. py.exe is located in c:\Windows\system32.exe, I modified the empty py.ini that was installed to contain 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. 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, but if it were in the current directory, it would just work). So when I: type c:\windows\system32\py.ini I get a set of h2 h3 v2 v3 commands in a section called [commands]. Not sure where my [defaults] went. Is there some more Windows magic to be explained? WOW6432-ness, perhaps? Probably my editor is running as a 32-bit process, so looked in the wrong C:\windows\system32 !! 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 is wrong? And why is the spacing around the = in the [commands] section so inconsistent? [defaults] python=3 [commands] h2=c:\Python26\python -h h3 = c:\Python32\python -h v2= c:\Python26\python -V v3 =c:\Python32\python -V OK, so when I specify: py d:\path\to\foo.py It fails, but this time it is because it launches Python 2.6.4. So the [defaults] section doesn't seem to have an effect.
On 20 July 2011 10:17, Glenn Linderman <v+python@g.nevcal.com> wrote:
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, but if it were in the current directory, it would just work).
type .\tt.py import sys
Just as a reference point: PS 12:26 D:\Data print sys.argv PS 12:26 D:\Data
py tt.py ['tt.py']
This is Windows XP 32-bit, using Powershell as my shell. Also works in cmd.exe. Paul.
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?
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.
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.
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. Regards, Vinay Sajip
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
Glenn Linderman wrote:
On 7/20/2011 7:19 AM, Vinay Sajip wrote:
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.
I would say that would be a cool enhancement, as it could save a bit of typing, but I think the launcher is quite useful even without path traversal. ~Ethan~
On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
I would say that would be a cool enhancement, as it could save a bit of typing, but I think the launcher is quite useful even without path traversal.
Two related points: 1. Walking PATH isn't necessary, but the cwd of the py process should be inherited from the shell correctly. If it is, then 'py foo.py' shouldn't need path traversal, it should just look in the current directory. Using PATHEXT to turn 'foo.py' directly into an executable command on PATH from any directory is different and out of scope for the launcher. 2. The defined launched command line handling means that "py -m foo" should also work, so long as the current directory is inherited correctly. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 7/20/2011 5:07 PM, Nick Coghlan wrote:
On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman<ethan@stoneleaf.us> wrote:
I would say that would be a cool enhancement, as it could save a bit of typing, but I think the launcher is quite useful even without path traversal. Two related points:
1. Walking PATH isn't necessary, but the cwd of the py process should be inherited from the shell correctly. If it is, then 'py foo.py' shouldn't need path traversal, it should just look in the current directory. Using PATHEXT to turn 'foo.py' directly into an executable command on PATH from any directory is different and out of scope for the launcher.
Sorry, I disagree that it is out of scope. Looking in the current directory is fine, when the script is there, but my scripts are seldom in my data directories, and I want to run scripts (from the PATH) on data that is in the CWD. I consider this a _very common_ use case for using scripts/programs, but then if you want to use py from the command line to tweak which version of Python gets used to execute the script (if the default one didn't work, for example, and you want to try a different one), then suddenly, you have to find the path to the script, and specify it explicitly.
2. The defined launched command line handling means that "py -m foo" should also work, so long as the current directory is inherited correctly.
Even if CWD is a data directory, and foo.py is somewhere on the path?
Cheers, Nick.
On 21/07/2011 10:18 AM, Glenn Linderman wrote:
On 7/20/2011 5:07 PM, Nick Coghlan wrote:
On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman<ethan@stoneleaf.us> wrote:
I would say that would be a cool enhancement, as it could save a bit of typing, but I think the launcher is quite useful even without path traversal. Two related points:
1. Walking PATH isn't necessary, but the cwd of the py process should be inherited from the shell correctly. If it is, then 'py foo.py' shouldn't need path traversal, it should just look in the current directory. Using PATHEXT to turn 'foo.py' directly into an executable command on PATH from any directory is different and out of scope for the launcher.
Sorry, I disagree that it is out of scope. Looking in the current directory is fine, when the script is there, but my scripts are seldom in my data directories, and I want to run scripts (from the PATH) on data that is in the CWD. I consider this a _very common_ use case for using scripts/programs, but then if you want to use py from the command line to tweak which version of Python gets used to execute the script (if the default one didn't work, for example, and you want to try a different one), then suddenly, you have to find the path to the script, and specify it explicitly.
The arguments above apply equally to python.exe. The launcher's job is to find an appropriate python.exe and launch it, not to locate the scripts and all the command-line parsing that would entail. If you want this feature you should advocate for it to be added to Python itself and it will then automatically work in the launcher too. Mark
On Thu, 21 Jul 2011 10:27:31 +1000, Mark Hammond <skippy.hammond@gmail.com> wrote:
On 21/07/2011 10:18 AM, Glenn Linderman wrote:
On 7/20/2011 5:07 PM, Nick Coghlan wrote:
On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman<ethan@stoneleaf.us> wrote:
I would say that would be a cool enhancement, as it could save a bit of typing, but I think the launcher is quite useful even without path traversal. Two related points:
1. Walking PATH isn't necessary, but the cwd of the py process should be inherited from the shell correctly. If it is, then 'py foo.py' shouldn't need path traversal, it should just look in the current directory. Using PATHEXT to turn 'foo.py' directly into an executable command on PATH from any directory is different and out of scope for the launcher.
Sorry, I disagree that it is out of scope. Looking in the current directory is fine, when the script is there, but my scripts are seldom in my data directories, and I want to run scripts (from the PATH) on data that is in the CWD. I consider this a _very common_ use case for using scripts/programs, but then if you want to use py from the command line to tweak which version of Python gets used to execute the script (if the default one didn't work, for example, and you want to try a different one), then suddenly, you have to find the path to the script, and specify it explicitly.
The arguments above apply equally to python.exe. The launcher's job is to find an appropriate python.exe and launch it, not to locate the scripts and all the command-line parsing that would entail. If you want this feature you should advocate for it to be added to Python itself and it will then automatically work in the launcher too.
Indeed. If I want to run a script with a different python version on a unix-like system, I need to know the path to said script. We're trying to make python as easy to use on Windows as it is on Unix. If find-script-on-path is considered a worthwhile feature, then as Mark said it should be added to base Python (on all platforms), not special-cased in the Windows launcher. -- R. David Murray http://www.bitdance.com
On Thu, Jul 21, 2011 at 12:52 PM, R. David Murray <rdmurray@bitdance.com> wrote:
Indeed. If I want to run a script with a different python version on a unix-like system, I need to know the path to said script. We're trying to make python as easy to use on Windows as it is on Unix. If find-script-on-path is considered a worthwhile feature, then as Mark said it should be added to base Python (on all platforms), not special-cased in the Windows launcher.
And given the diverse range of what Python considers to be an executable script these days, -1000 to that particular feature. Use `which scriptname`, that's what it's for. The lack of such functionality in the underpowered cmd shell on Windows isn't Python's problem to solve - ask MS for a better shell and command line utilities (assuming Powershell doesn't already offer something comparable to 'which'). There are reasons I only code specifically for Windows if someone pays me to do so :P Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 7/20/2011 8:22 PM, Nick Coghlan wrote:
Indeed. If I want to run a script with a different python version on a unix-like system, I need to know the path to said script. We're trying to make python as easy to use on Windows as it is on Unix. If find-script-on-path is considered a worthwhile feature, then as Mark said it should be added to base Python (on all platforms), not special-cased in the Windows launcher. And given the diverse range of what Python considers to be an executable script these days, -1000 to that particular feature. Use `which scriptname`, that's what it's for. The lack of such functionality in the underpowered cmd shell on Windows isn't Python's
On Thu, Jul 21, 2011 at 12:52 PM, R. David Murray<rdmurray@bitdance.com> wrote: problem to solve - ask MS for a better shell and command line utilities (assuming Powershell doesn't already offer something comparable to 'which').
There are reasons I only code specifically for Windows if someone pays me to do so :P
Interesting feedback. Well, I have a "which" program on my machine, but as a 32-bit executable, it won't find py in the 64-bit c:\windows\system32 directory! Another good reason to demand pay for Windows programming. There are some interesting gotchas to the way 32- vs 64-bit "compatibility" is achieved in Windows (groan). I'll find or write a better one, in due time. Meantime, the launcher testing has been a good learning exercise for me. Interesting, David, that you feel it that Python usability on Windows should be limited to its usability on Unix, rather than to exceed it. I don't see that as a necessary or appropriate limit. Windows and Unix are different. Unix people are accustomed to using tools like which, and using command lines, and path manipulations; Windows people are not. So the use of the command line is already somewhat foreign to them, and limiting the launcher so that they have to use other command line tools to get the work done, would only serve to frustrate them. Now the argument can possibly be made that people that want to use launcher from the command line would be those that are already command line experts might be realistic, but I will note that Perl has a -S option to find its script on the PATH, not that that is a sufficient reason to add such to Python, or even to the launcher, but just to note that there are at least some people besides myself that might think that is a friendly idea. My goal in writing software is to make it easy to use, regardless of whether some other system should be the responsible party or not -- especially when I don't control the other system. But then, I haven't found time to write a competing launcher, either, with friendlier features. So, I'll just reiterate that I would find it friendly if the launcher searched the path to find the script, and agree that if Python had a feature to do so, that would also be friendly to the Windows platform, but less necessary on Unix where you can `which script.py` (although that would still require more typing than if the path searching were automatic.
On Thu, Jul 21, 2011 at 6:06 PM, Glenn Linderman <v+python@g.nevcal.com> wrote:
Interesting, David, that you feel it that Python usability on Windows should be limited to its usability on Unix, rather than to exceed it. I don't see that as a necessary or appropriate limit. Windows and Unix are different. Unix people are accustomed to using tools like which, and using command lines, and path manipulations; Windows people are not. So the use of the command line is already somewhat foreign to them, and limiting the launcher so that they have to use other command line tools to get the work done, would only serve to frustrate them. Now the argument can possibly be made that people that want to use launcher from the command line would be those that are already command line experts might be realistic, but I will note that Perl has a -S option to find its script on the PATH, not that that is a sufficient reason to add such to Python, or even to the launcher, but just to note that there are at least some people besides myself that might think that is a friendly idea.
If a PEP is put forward proposing such a feature, with a reference implementation that supports at least Windows, *nix and OS X and works for at least the 4 script types understood by the CPython executable without a command line option (source and bytecode files along with directories and zipfiles providing top level __main__ modules), then I'd be prepared to moderate my response all the way to a +0 (reserving the extreme negative reaction for proposals that are either platform specific or only handle some script types). I believe that is significantly easier said than done, though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, 21 Jul 2011 01:06:57 -0700, Glenn Linderman <v+python@g.nevcal.com> wrote:
Interesting, David, that you feel it that Python usability on Windows should be limited to its usability on Unix, rather than to exceed it. I don't see that as a necessary or appropriate limit. Windows and Unix
That wasn't how I intended my comment. My point was that the goal of the *PEP* is to make it "as usable" (and actually just in the specific case of #! lines), and that if the additional feature is desirable why not make it available on all platforms? I can see how you read what you did in what I wrote, though. -- R. David Murray http://www.bitdance.com
On 21/07/2011 7:43 AM, Glenn Linderman wrote: ...
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.
It doesn't do exactly what you ask, but setting an environment variable PYLAUNCH_DEBUG to any value will cause some debug output to be generated to stdout. Mark
On 7/20/2011 4:41 PM, Mark Hammond wrote:
On 21/07/2011 7:43 AM, Glenn Linderman wrote: ...
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.
It doesn't do exactly what you ask, but setting an environment variable PYLAUNCH_DEBUG to any value will cause some debug output to be generated to stdout.
Mark
It produces: d:\>py d:\path\to\foo.py launcher build: 64bit launcher executable: Console File 'C:\Users\Glenn\AppData\Roaming\py.ini' non-existent maybe_handle_shebang: read 256 bytes maybe_handle_shebang: BOM not found, using UTF-8 locate_pythons_for_key: unable to open PythonCore key locate_pythons_for_key: unable to open PythonCore key run_child: about to run 'C:\Python26\python.exe d:\path\to\foo.py' File "d:\path\to\foo.py", line 469 child process exit code: 1 So this tells me that it didn't find a local py.ini (no surprise, I don't have one) but doesn't tell me that it did find or read c:\Windows\system32\py.ini much less whether I have the syntax correct for my [defaults] section. It doesn't tell me that it didn't find a #! line (but there isn't one). Perhaps the problem is that there isn't one? If it finds no virtual command, maybe it doesn't obey the [defaults] python=3 directive? The PEP says it should act like '!#python' (I think the PEP meant '#!python', though????). There is no " " after '!#python' in the PEP, so that disqualifies it from being a customized command, there is no '/usr/bin/' nor '/usr/bin/env ' in front of the 'python' so that means it is not a virtual command; and it is not a fully-qualified name, so it doesn't mean that case either.... looks like the PEP needs a bit of clarification here. I do have a python on my path, but it is 3.1.2, not 3.2.1 or 2.6.4, and it runs 2.6.4 as the output shows. And I would expect it to run 3.2.1 with the [defaults] python=3 directive, since that is newer than 3.1.2, which is on my PATH. So, still a mystery.
On 21/07/2011 10:02 AM, Glenn Linderman wrote:
So this tells me that it didn't find a local py.ini (no surprise, I don't have one) but doesn't tell me that it did find or read c:\Windows\system32\py.ini much less whether I have the syntax correct for my [defaults] section. It doesn't tell me that it didn't find a #! line (but there isn't one).
I'll have a go at enhancing the debug output for most of the above (although note that if it *did* find a shebang line extra output would have been generated.)
Perhaps the problem is that there isn't one? If it finds no virtual command, maybe it doesn't obey the [defaults] python=3 directive? The PEP says it should act like '!#python' (I think the PEP meant '#!python', though????). There is no " " after '!#python' in the PEP, so that disqualifies it from being a customized command, there is no '/usr/bin/' nor '/usr/bin/env ' in front of the 'python' so that means it is not a virtual command; and it is not a fully-qualified name, so it doesn't mean that case either.... looks like the PEP needs a bit of clarification here.
I'm not sure the PEP needs clarification - possibly just the implementation ;) But let me know if you think otherwise.
I do have a python on my path, but it is 3.1.2, not 3.2.1 or 2.6.4, and it runs 2.6.4 as the output shows.
FYI, what is on the path isn't relevant to the launcher.
And I would expect it to run 3.2.1 with the [defaults] python=3 directive, since that is newer than 3.1.2, which is on my PATH.
It may be that your copy of the launcher is a little old - some changes were pushed just yesterday (but I'm not sure if Vinay made a new installer yet). It has slightly better debug output (although generally not what you are asking for yet) and better "cross-bittedness" support. Cheers, Mark
On 7/20/2011 5:11 PM, Mark Hammond wrote:
On 21/07/2011 10:02 AM, Glenn Linderman wrote:
So this tells me that it didn't find a local py.ini (no surprise, I don't have one) but doesn't tell me that it did find or read c:\Windows\system32\py.ini much less whether I have the syntax correct for my [defaults] section. It doesn't tell me that it didn't find a #! line (but there isn't one).
I'll have a go at enhancing the debug output for most of the above (although note that if it *did* find a shebang line extra output would have been generated.)
Perhaps the problem is that there isn't one? If it finds no virtual command, maybe it doesn't obey the [defaults] python=3 directive? The PEP says it should act like '!#python' (I think the PEP meant '#!python', though????). There is no " " after '!#python' in the PEP, so that disqualifies it from being a customized command, there is no '/usr/bin/' nor '/usr/bin/env ' in front of the 'python' so that means it is not a virtual command; and it is not a fully-qualified name, so it doesn't mean that case either.... looks like the PEP needs a bit of clarification here.
I'm not sure the PEP needs clarification - possibly just the implementation ;) But let me know if you think otherwise.
Well, at least !# should be changed to #! :) And then the example of "customized command" shows "#! vpython" with the space before the vpython, but the text describes the necessary space as being after the customized command, at least the way I read it. So I really don't know whether the example is showing an extraneous space after the ! (and not one after vpython) or exactly what is meant.
I do have a python on my path, but it is 3.1.2, not 3.2.1 or 2.6.4, and it runs 2.6.4 as the output shows.
FYI, what is on the path isn't relevant to the launcher.
I didn't expect it to be, I just mentioned it in passing, because the launcher doesn't seem to be doing what I expect it to do, but neither does it seem to be using the PATH to find a Python either.
And I would expect it to run 3.2.1 with the [defaults] python=3 directive, since that is newer than 3.1.2, which is on my PATH.
It may be that your copy of the launcher is a little old - some changes were pushed just yesterday (but I'm not sure if Vinay made a new installer yet). It has slightly better debug output (although generally not what you are asking for yet) and better "cross-bittedness" support.
Cheers,
Mark
Mine's a week old, yes.
On 7/20/2011 5:11 PM, Mark Hammond wrote:
It may be that your copy of the launcher is a little old - some changes were pushed just yesterday (but I'm not sure if Vinay made a new installer yet). It has slightly better debug output (although generally not what you are asking for yet) and better "cross-bittedness" support.
Installed new version: msiexec /i launchwin.amd64.msi ALLUSERS=1 Expected behaviors of registry changes occurred. Still launches python 2, though, whereas c:\windows\py.ini contains: [defaults] python=3 [commands] /usr/bin/perl=C:\perl\bin\perl.exe Here is the debug output. Seems like it isn't recognizing the python=3, even the new version. d:\path\to\data>>set PYLAUNCH_DEBUG=1 set PYLAUNCH_DEBUG=1 d:\path\to\data>foo.py --pyver --clean foo.py --pyver --clean launcher build: 64bit launcher executable: Console File 'C:\Users\Glenn\AppData\Roaming\py.ini' non-existent Using global configuration file 'C:\Windows\py.ini' maybe_handle_shebang: read 256 bytes maybe_handle_shebang: BOM not found, using UTF-8 locating Pythons in 32bit registry locate_pythons_for_key: unable to open PythonCore key in HKCU locate_pythons_for_key: C:\Python26\python.exe is a 32bit executable locate_pythons_for_key: C:\Python26\PCBuild\python.exe: The system cannot find the path specified. locate_pythons_for_key: C:\Python26\PCBuild\amd64\python.exe: The system cannot find the path specified. locate_pythons_for_key: C:\Python31\python.exe is a 32bit executable locate_pythons_for_key: C:\Python31\PCBuild\python.exe: The system cannot find the path specified. locate_pythons_for_key: C:\Python31\PCBuild\amd64\python.exe: The system cannot find the path specified. locating Pythons in native registry locate_pythons_for_key: unable to open PythonCore key in HKCU locate_pythons_for_key: C:\Python32\python.exe is a 64bit executable locate_pythons_for_key: C:\Python32\PCBuild\python.exe: The system cannot find the path specified. locate_pythons_for_key: C:\Python32\PCBuild\amd64\python.exe: The system cannot find the path specified. found no configured value for 'python' search for default Python found version 2.6 at 'C:\Python26\python.exe' run_child: about to run 'C:\Python26\python.exe "D:\my\py\foo.py" --pyver --clean' File "D:\my\py\foo.py", line 469 SyntaxError: Non-ASCII character '\xc3' in file D:\my\py\foo.py on line 470, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details child process exit code: 1 d:\path\to\data> So, looking at the code, get_configured_value produces that message, but there are 3 places to look for "python". Setting the environment variable makes it work. Eliminating the environment variable, I then copied c:\Windows\py.ini to c:\users\glenn\appdata\roaming\py.ini. That worked. So I guess the syntax of my py.ini file is correct. But apparently it isn't properly using c:\windows\py.ini !! Yet curiously, it reports the correct name for the global configuration file. Aha! Bad logic is get_configured_value! get_configured_value only looks in the global configuration file if there is a local configuration file that doesn't have the setting. It should look in the global configuration file if there is no local configuration file _OR_ the is a local configuration file without the setting. I'll await a new launcher.
On 22/07/2011 9:02 AM, Glenn Linderman wrote:
Bad logic is get_configured_value! get_configured_value only looks in the global configuration file if there is a local configuration file that doesn't have the setting. It should look in the global configuration file if there is no local configuration file _OR_ the is a local configuration file without the setting.
I'll await a new launcher.
I just pushed a fix and hopefully Vinay will push a new MSI soon. Thanks, Mark
On 7/21/2011 5:44 PM, Mark Hammond wrote:
On 22/07/2011 9:02 AM, Glenn Linderman wrote:
Bad logic is get_configured_value! get_configured_value only looks in the global configuration file if there is a local configuration file that doesn't have the setting. It should look in the global configuration file if there is no local configuration file _OR_ the is a local configuration file without the setting.
I'll await a new launcher.
I just pushed a fix and hopefully Vinay will push a new MSI soon.
Thanks,
Mark
What (free?) toolset is needed for building the launcher? I don't even have a C compiler installed on this computer yet.
Glenn Linderman <v+python <at> g.nevcal.com> writes: I aim to update the launcher downloads Real Soon Now.
What (free?) toolset is needed for building the launcher? I don't even have a C compiler installed on this computer yet.
The tools I use for building the launcher are: Windows SDK (for the 64-bit compilers), Visual Studio Express C++ (2008 Edition), WiX for the installers, and Python. All are free as in beer, and some are also free as in speech. Regards, Vinay Sajip
On 7/23/2011 5:34 AM, Vinay Sajip wrote:
Glenn Linderman<v+python<at> g.nevcal.com> writes:
I aim to update the launcher downloads Real Soon Now.
Has fixed my problem with not having a local py.ini file, and now is picking up python=3 from the py.ini coresident to the py.exe. Thanks, Mark & Vinay.
On 7/20/2011 2:43 PM, Glenn Linderman wrote:
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.
The Windows SearchPath API <http://msdn.microsoft.com/en-us/library/aa365527%28v=VS.85%29.aspx> makes it a pretty easy job to walk the PATH. Would even allow low cost additional feature of searching for both foo and foo.py at the same time.
On 21/07/2011 10:13 AM, Glenn Linderman wrote:
On 7/20/2011 2:43 PM, Glenn Linderman wrote:
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.
The Windows SearchPath API <http://msdn.microsoft.com/en-us/library/aa365527%28v=VS.85%29.aspx> makes it a pretty easy job to walk the PATH. Would even allow low cost additional feature of searching for both foo and foo.py at the same time.
But that would also require us to parse the command-line, understand which options require 2 args and which just require 1 (making it fragile in the face of later versions introducing new options), then re-stitching a modified command-line back together for the child process. IMO that is all out of scope. Are you maybe forgetting about the PATHEXT functionality? If you include .py in your PATHEXT and file associations are set so .py files are handled by the launcher, you should be able to directly execute just 'foo' and have the command processor search the PATH for a foo.py and invoke it via the launcher. Mark
On 7/20/2011 5:34 PM, Mark Hammond wrote:
On 21/07/2011 10:13 AM, Glenn Linderman wrote:
On 7/20/2011 2:43 PM, Glenn Linderman wrote:
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.
The Windows SearchPath API <http://msdn.microsoft.com/en-us/library/aa365527%28v=VS.85%29.aspx> makes it a pretty easy job to walk the PATH. Would even allow low cost additional feature of searching for both foo and foo.py at the same time.
But that would also require us to parse the command-line, understand which options require 2 args and which just require 1 (making it fragile in the face of later versions introducing new options), then re-stitching a modified command-line back together for the child process. IMO that is all out of scope.
Yes it would be more work.
Are you maybe forgetting about the PATHEXT functionality? If you include .py in your PATHEXT and file associations are set so .py files are handled by the launcher, you should be able to directly execute just 'foo' and have the command processor search the PATH for a foo.py and invoke it via the launcher.
Not at all. I was just testing the use of the launcher from the command line, and seeing the cumbersomeness of using it as a prefix to a command that would work on its own, but fails when launched by the launcher from the command line. And the SearchPath API has a limited form of PATHEXT support built in, which is what I was trying to point out above. Yes, the use of the launcher via file associations can be friendly because it leverages Windows features, but its use from the command line presently seems rather unfriendly, because it leverages Windows misfeatures.
Mark
On 21 July 2011 09:13, Glenn Linderman <v+python@g.nevcal.com> wrote:
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.
It's equally as arguable (and would match my expectations much more closely) that "py a_file.py" should do whatever "python a_file.py" would do. So path search in that context would only be reasonable if it were a Python feature rather than a feature of the launcher. This is what the launcher currently does (so I guess it's not surprising that I'm happy with the current behaviour). I can see the benefits of path search, but I'd want it to be a Python feature (and hence inherited "for free" by the launcher) and not a launcher-only one. Paul.
On 21/07/2011 15:43, Paul Moore wrote:
On 21 July 2011 09:13, Glenn Linderman<v+python@g.nevcal.com> wrote:
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. It's equally as arguable (and would match my expectations much more closely) that "py a_file.py" should do whatever "python a_file.py" would do. So path search in that context would only be reasonable if it were a Python feature rather than a feature of the launcher.
This is what the launcher currently does (so I guess it's not surprising that I'm happy with the current behaviour).
I can see the benefits of path search, but I'd want it to be a Python feature (and hence inherited "for free" by the launcher) and not a launcher-only one.
What he said ^^. (+1) py launcher and python binaries behaving differently in this regard would be a recipe for confusion and hard to debug problems. Michael
Paul. _______________________________________________ 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/fuzzyman%40voidspace.org.u...
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On 7/21/2011 8:20 AM, Michael Foord wrote:
On 21/07/2011 15:43, Paul Moore wrote:
On 21 July 2011 09:13, Glenn Linderman<v+python@g.nevcal.com> wrote:
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. It's equally as arguable (and would match my expectations much more closely) that "py a_file.py" should do whatever "python a_file.py" would do. So path search in that context would only be reasonable if it were a Python feature rather than a feature of the launcher.
This is what the launcher currently does (so I guess it's not surprising that I'm happy with the current behaviour).
I can see the benefits of path search, but I'd want it to be a Python feature (and hence inherited "for free" by the launcher) and not a launcher-only one.
What he said ^^. (+1)
py launcher and python binaries behaving differently in this regard would be a recipe for confusion and hard to debug problems.
I see the point. Although the incremental benefit is higher to Windows users, and although we are creating a Windows-only piece of code that could be the vehicle for adding the functionality, it would be beneficial for all platforms, and a common implementation would serve that need better.
On Fri, Jul 22, 2011 at 6:05 AM, Glenn Linderman <v+python@g.nevcal.com> wrote:
On 7/21/2011 8:20 AM, Michael Foord wrote:
py launcher and python binaries behaving differently in this regard would be a recipe for confusion and hard to debug problems.
I see the point. Although the incremental benefit is higher to Windows users, and although we are creating a Windows-only piece of code that could be the vehicle for adding the functionality, it would be beneficial for all platforms, and a common implementation would serve that need better.
Well that, and the desire to have the Windows launcher *just* find an interpreter to run, so that "py -3.2 <args>" and "c:\python32\python <args>" handle the arguments the same way. While further discussion of the PATH walking concept should be done in a new thread on python-ideas, I'll note that I'm no longer actively opposed to the idea. However, I still think it needs its own PEP to work out the details (and whether or not it happens at all). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (11)
-
Anthony Kong -
Ethan Furman -
Glenn Linderman -
Mark Hammond -
Mark Hammond -
Michael Foord -
Nick Coghlan -
Paul Moore -
R. David Murray -
Terry Reedy -
Vinay Sajip