On 7/03/2011 3:30 PM, Glenn Linderman wrote:
I'm only against the overhead of a helper written in Python, since it would have to launch Python (some explicit version) to run the helper script, and then launch the "right" version of Python to execute the real script. You mention a thin executable wrapper, and I have no problem with the overhead of that, probably.
Yeah - I think any such wrapper could be a reasonably small C program - although I guess that depends on the decided functionality :) ...
Since Windows does not use a #! line, then the solutions for (2) must be different. The ones that I can think of are:
(A) declare the Python version in the name of the script file. By doing so in the extension, additional Windows associations could be created to launch different versions of Python. Switching versions would be as simple as renaming the file, changing the extension to include a different version. However, various tools would have to learn about additional extensions that mean Python (syntax directed editors, etc.) And it would be hard to have a script in a module, unless the importer recognized all those extensions too. So this "solution" has ripple effects that make it unattractive, although it is simple to implement the basic feature.
Agreed - I find this unattractive.
(B) declare the Python version in the content of the script file. This cures most of the ripple effects of the above, but requires a "launcher" or "wrapper" program to be designed, implemented, and installed. There are a variety of subsolutions for different ways of declaring the version.
<snip a few options> Without putting too much thought into it, I think a simple scheme could work where the path must either be "/usr/bin/python[23]?" or a fully-qualified path to a Python executable. IIUC, this should allow most scripts to have a shebang line that "does the right thing" on *nix and Windows systems while still offering maximum flexibility on Windows.
By default, for Python, the wrapper would get associated only with .py files.
There would probably also need to be the same for ".pyw", but it would be almost identical to the .py handling. Cheers, Mark