[Thomas Heller wrote]
There is a bug in the current cmd.exe (or maybe it is only up to Win2k? can't remember) where shell redirection doesn't work if your script is launched indirectly via a .bat of .cmd file. As well, Ctrl+C signal handling for kill a script is quite annoying if launched via a .bat file: you get a secondary question from the shell
Terminate batch file (Y/N)?
or something like that. A .exe launcher/stub is definitely preferred.
Isn't the shell redirection problem also present if the .py script is run via the shell association?
Oh shoot, I think I was wrong and you are right: the shell redirection problem is for the case of using the PATHEXT stuff. I.e. I think shell redirection works fine with a .bat or .cmd stub. Sorry about causing confusion.
The Ctrl+C behaviour annoys me also because I usually run my scripts via batch files (py23.bat, py24.bat, py_d.bat and so on). Maybe this problem can be avoided by copying the python.exe's somewhere to my path, with names p23.exe, p24.exe and so on. They only contain a pointer to the actual PythonXY.dll name, afaik. So I don't have to update p24.exe when I install 2.4.2 over my 2.4.1.
I tend to copy python.exe to pythonXY.exe (as appropriate) after I install a new Python. I'm considering doing this by default in the ActivePython installers I make. (Similar to the pythonX.Y executable copies that get made on Linux/Un*x.) What do you think?
Somewhat similar to the exemaker approach, but using the name of the exe to specify the Python version instead of a '-i ...' command line option, or the #! line in the script.
Agreed.
The only missing piece so far, for me at least, is that it's not possible to use dotted module names with the -m option:
p24 -m ctypes.wrap.h2xml windows.h
That's too bad. I didn't know "-m" didn't support that... but then I haven't really used it that much yet. Trent -- Trent Mick TrentM@ActiveState.com