On 7/25/2010 5:57 PM, Thomas Jollans wrote:
On 07/25/2010 11:10 PM, Edward Diener wrote:
On 7/25/2010 3:39 PM, Christian Heimes wrote:
Am 25.07.2010 21:32, schrieb Thomas Jollans:
If a script uses sys.executable instead of "python", there is no
problem, at all.
It's true that sys.executable is the best way if you have to start a new
Python interpreter. However sys.executable may not be set for NT
services. So there may be a problem after all.
Once you start instrusively changing scripts to find a solution to
multiple versions of Python co-existing in one system, you are heading
down a path of endless problems.
What exactly is it that you're afraid to change?
I do not want to intrusively change any script that has been installed
as part of Python. I shouldn't even have to know about the code in these
scripts other than what good documentation tells me in how to use them.
That's not to say having source is worthless. I am just not going to
change source to get a version of Python to work properly when I have 2
or more versions installed in their own separate folders.
The standard library? There's certainly no need to change that in any way!
So if a standard library module ( or distributed library ) executes a
call internally to 'python xxx yyy' or executes a call internally to
'someScript.py yyy', you're fine with multiple co-existing versions of
Python on your system ?
Because under Windows the first call will look for the python.exe first
found in the PATH while the second call will find the python.exe
associated with the .py extension. And it does not matter in either case
what version of the multiple installed versions of Python which are on
my system is currently executing that script.
And please don't say that there is some sort of guarantee that no
library or installation would invoke Python in such a way as opposed to
the normal 'import AScript.py' method of using functionality in Python
scripts.
--
http://mail.python.org/mailman/listinfo/python-list
