On 7/25/2010 10:42 PM, David Robinow wrote:
On Sun, Jul 25, 2010 at 8:40 PM, Edward Diener
<eldie...@tropicsoft.invalid> wrote:
On 7/25/2010 5:57 PM, Thomas Jollans wrote:
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.
Edward, I'm having a really hard time understanding your problem.
Could you give an example of some real code that is causing you
difficulty?
I start a Python script for version X by going to X's root directory and
invoking 'python someScript.py' from the command line. Does that not
sound reasonable ?
In SomeScript.py there is an internal call to 'python someOtherScript.y
someParameters'. But the call invokes another version of Python because
it is that version which is in the PATH. Or in SomeScript.py there is an
internal call to 'someOtherScript.py someParameters'. But the call
invokes another version of Python because the .py extension is
associated with a different version.
My solution is that I will write some code which sets a particular
version of Python as the current version for a particular time, meaning
that version will be in the PATH and associated with Python extensions.
The way I do not have to worry when I externally invoke Python from the
command line that internal calls are going to some other version.
--
http://mail.python.org/mailman/listinfo/python-list
