On 07/26/2010 06:36 AM, Edward Diener wrote: > 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 ?
yeah, well, sort of. But for a system installation, not really. When hacking on the interpreter, this makes sense. Otherwise - not so much. > > In SomeScript.py there is an internal call to 'python someOtherScript.y > someParameters'. Is that a fact? Where on earth did you get this "SomeScript.py"? -- http://mail.python.org/mailman/listinfo/python-list
