Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Multiple versions of Python coexisting in the same OS

Reply
Thread Tools

Multiple versions of Python coexisting in the same OS

 
 
News123
Guest
Posts: n/a
 
      07-25-2010
On 07/25/2010 10:18 PM, Thomas Jollans wrote:
> On 07/25/2010 10:04 PM, News123 wrote:
>> sOn 07/25/2010 09: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.

>>
>>
>> sys.executable will not work with scripts converted with py2exe,
>> as sys.executable will not be the executable of the python interpreter,
>> but with the main executable's name.

>
> Well, but a script converted with py2exe can't really ever assume that
> there is a Python interpreter, at all.


true


However, why I thought about this is, that
I write sometimes python code, which tries to call other python files.

later on for distribution I use py2exe.

Therefore I use wrapper functions, which will work in either case.

The wrapper could use sys.executable in 'python mode'
and had to call the exe file in 'py2exe mode'

 
Reply With Quote
 
 
 
 
MRAB
Guest
Posts: n/a
 
      07-25-2010
News123 wrote:
> On 07/25/2010 09:33 PM, Edward Diener wrote:
>> On 7/25/2010 10:31 AM, News123 wrote:
>>> On 07/25/2010 02:46 PM, Edward Diener wrote:
>>>> On 7/25/2010 6:07 AM, Gelonida wrote:

>
>> How does a 'pystarter' program know where the file's location is which
>> is being invoked ?

> the file's location would be somewhere in sys.argv
> probably in sys.argv[1].
> converting it to an abs path would return a directory which the python
> file belongs to.
>
>
>> As to the first file line this is completely
>> unrealistic. What are you going to do, alter the first file line of
>> every script in a Python distribution and every script in every library
>> installed in a Python distribution ? Sorry, but a less intrusive
>> solution is much better and much less of a headache to say the least.
>>

> Well I would at least do it for all of my self written scripts.
>
> It could allow a soft transition from 2.6 to 2.7 to 3.0 without having
> to upgrade all scripts at the same time.
>
>> My intended solution would be a simple program which understands where
>> each co-existing Python distribution is installed on a system and what
>> the "name" of that distribution is. Then you tell the program which
>> Python distribution should be the current one by its "name", the current
>> one meaning the distribution which you want to be invoked at any given
>> time. The program then changes the PATH so that any references to the
>> Python directory and its subdirectories point to the "name" Python
>> directory tree, and changes the file associations so that the "name"
>> Python executables handle the Python associations.

>
>
>> This does have the weakness that I can not use more than one Python
>> distribution while Python is executing scripts. But I can personally
>> live with that since I have never encountered a situation where I must
>> use more than one Python distribution at the same time.
>>

>
> I guess it's rather difficult to find a solution which suits all.
>
> The above minor weakness, that you mention would be a killer for me.
>
> Currently I'm looking for solutions, where I can start python scripts
> requireing different python versions at the same time.
>
> Currently I'm staring the scripts manually from two different cmd line
> windows with a different path name and an explicit python call,
>
> Thus my idea of having a pystarter with a config file
> mentioning which directories (tools) should use which python executable
>

I think that's the wrong way round. A pystarter should ask the _tool_
which version of Python it needs.
 
Reply With Quote
 
 
 
 
Edward Diener
Guest
Posts: n/a
 
      07-25-2010
On 7/25/2010 3:32 PM, Thomas Jollans wrote:
> On 07/25/2010 09:19 PM, Edward Diener wrote:
>> On 7/25/2010 10:03 AM, Thomas Jollans wrote:
>>> On 07/25/2010 02:46 PM, Edward Diener wrote:
>>>> The problem with this is that you forget that a script can invoke Python
>>>> internally. So whether one uses the console or file association method
>>>> of invoking Python externally, any already written script can use either
>>>> internally.
>>>
>>> Maybe it's just me, but I think that a script that does this is quite
>>> simply badly written: it *will* break on systems that have multiple
>>> Python versions.

>>
>> Whether it is badly written or not in your opinion it is legal and
>> happens all the time. Are you going to refuse to use any script, no
>> matter for what library or for what purpose, that internally invokes
>> Python either through a 'python' command or through a file with a Python
>> extension ? And how would you find out if a script did this or not ? Are
>> going to search every script in every distribution and library to
>> determine if it does this ? And when you find out a script does this,
>> what will you do ?
>>
>> Be real. saying you do not like scripts that internally invoke Python
>> does not solve anything if you have multiple coexisting versions of
>> Python installed.

>
> I doubt many scripts do it. The fact of the matter is: many systems have
> multiple Python versions installed in parallel, and it probably will
> break somewhere, which will get noticed, and probably fixed.
>
> If a script uses sys.executable instead of "python", there is no
> problem, at all.


What a script uses to internally invoke Python I can not control. My
solution seeks to be non-intrusive and lets me run a particular version
of Python, among the co-existing versions installed, at any given time.
I believe that is the best I can do. I neither can control, nor do I
want to control, all of the Python scripts installed on my system, nor
can I worry how they may internally invoke Python. But I do want to be
able to say, at any given time, that when I run Python a particular
version, amidst the co-existing ones on my system, needs to be executed
and therafter all internally executed modules use that version.

Trying to make rules for scripts, such as telling scripts they must use
sys.executable, is pursuing an imaginary solution that can not work
unless one is theoretically willing to manually inspect and change all
Python scripts in some way. To me any intrusive changes to actual
scripts is no solution at all.
 
Reply With Quote
 
Edward Diener
Guest
Posts: n/a
 
      07-25-2010
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.
 
Reply With Quote
 
Edward Diener
Guest
Posts: n/a
 
      07-25-2010
On 7/25/2010 4:22 PM, News123 wrote:
> On 07/25/2010 09:33 PM, Edward Diener wrote:
>> On 7/25/2010 10:31 AM, News123 wrote:
>>> On 07/25/2010 02:46 PM, Edward Diener wrote:
>>>> On 7/25/2010 6:07 AM, Gelonida wrote:

>
>>
>> How does a 'pystarter' program know where the file's location is which
>> is being invoked ?

> the file's location would be somewhere in sys.argv
> probably in sys.argv[1].
> converting it to an abs path would return a directory which the python
> file belongs to.
>
>
>> As to the first file line this is completely
>> unrealistic. What are you going to do, alter the first file line of
>> every script in a Python distribution and every script in every library
>> installed in a Python distribution ? Sorry, but a less intrusive
>> solution is much better and much less of a headache to say the least.
>>

> Well I would at least do it for all of my self written scripts.
>
> It could allow a soft transition from 2.6 to 2.7 to 3.0 without having
> to upgrade all scripts at the same time.


Intrusively changing scripts is a path to Python hell.

>
>> My intended solution would be a simple program which understands where
>> each co-existing Python distribution is installed on a system and what
>> the "name" of that distribution is. Then you tell the program which
>> Python distribution should be the current one by its "name", the current
>> one meaning the distribution which you want to be invoked at any given
>> time. The program then changes the PATH so that any references to the
>> Python directory and its subdirectories point to the "name" Python
>> directory tree, and changes the file associations so that the "name"
>> Python executables handle the Python associations.

>
>
>>
>> This does have the weakness that I can not use more than one Python
>> distribution while Python is executing scripts. But I can personally
>> live with that since I have never encountered a situation where I must
>> use more than one Python distribution at the same time.
>>

>
> I guess it's rather difficult to find a solution which suits all.
>
> The above minor weakness, that you mention would be a killer for me.
>
> Currently I'm looking for solutions, where I can start python scripts
> requireing different python versions at the same time.


If you need that, then of course my intended solution would not work.

>
> Currently I'm staring the scripts manually from two different cmd line
> windows with a different path name and an explicit python call,


If you start scripts and point to a specific version of Python, this
works in my solution also. But if an internal call to Python exists
thwre is always a problem.

>
> Thus my idea of having a pystarter with a config file
> mentioning which directories (tools) should use which python executable


Well, good luck ! I don;t know how this is resolved for you when some
scripts executes 'python xxx yyy' or 'someScript.py yyy'.
 
Reply With Quote
 
Edward Diener
Guest
Posts: n/a
 
      07-25-2010
On 7/25/2010 4:26 PM, News123 wrote:
> On 07/25/2010 10:18 PM, Thomas Jollans wrote:
>> On 07/25/2010 10:04 PM, News123 wrote:
>>> sOn 07/25/2010 09: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.
>>>
>>>
>>> sys.executable will not work with scripts converted with py2exe,
>>> as sys.executable will not be the executable of the python interpreter,
>>> but with the main executable's name.

>>
>> Well, but a script converted with py2exe can't really ever assume that
>> there is a Python interpreter, at all.

>
> true
>
>
> However, why I thought about this is, that
> I write sometimes python code, which tries to call other python files.
>
> later on for distribution I use py2exe.
>
> Therefore I use wrapper functions, which will work in either case.
>
> The wrapper could use sys.executable in 'python mode'
> and had to call the exe file in 'py2exe mode'
>


You can control what you do but how are you going to control what any
givemn script does ?

Attempting to intrusively change potentially every script in a
distribution in any way is a path to Python hell IMO.
 
Reply With Quote
 
Edward Diener
Guest
Posts: n/a
 
      07-26-2010
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.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-26-2010
On Sun, 25 Jul 2010 15:19:53 -0400, Edward Diener wrote:

> On 7/25/2010 10:03 AM, Thomas Jollans wrote:
>> On 07/25/2010 02:46 PM, Edward Diener wrote:
>>> The problem with this is that you forget that a script can invoke
>>> Python internally. So whether one uses the console or file association
>>> method of invoking Python externally, any already written script can
>>> use either internally.

>>
>> Maybe it's just me, but I think that a script that does this is quite
>> simply badly written: it *will* break on systems that have multiple
>> Python versions.

>
> Whether it is badly written or not in your opinion it is legal and
> happens all the time.


Yes, people write poorly written, buggy scripts all the time. Just
because code is legal syntax doesn't mean it does what is intended, or
that what is intended is sensible.

If you have multiple versions of Python installed, and you call "python
somescript.py" without knowing *which* Python will be called, it is
neither sensible nor does it do what you intend. End of story.

This is no different from calling any other application without knowing
what version you will get, then relying on features that are only
available in some versions. It is just buggy code.


> Are you going to refuse to use any script, no
> matter for what library or for what purpose, that internally invokes
> Python either through a 'python' command or through a file with a Python
> extension ? And how would you find out if a script did this or not ? Are
> going to search every script in every distribution and library to
> determine if it does this ? And when you find out a script does this,
> what will you do ?


Treat it like any script with a bug: fix the bug, stop using the script,
or determine a work-around that masks the bug. All three are acceptable,
the third being the least acceptable because it just leaves a bug waiting
to bite you again in the future.


> Be real. saying you do not like scripts that internally invoke Python
> does not solve anything if you have multiple coexisting versions of
> Python installed.


No, it solves it completely. Treat it as a bug, and fix it.

If you're not willing to treat it as a bug, then uninstall all but one of
the Python versions, and the problem goes away. You might have a
different problem, namely that some scripts stop working, but now the
solution is obvious and straight-forward: fix the scripts that aren't
working.

Or rename the Python applications, so that scripts can easily call the
right version without getting confused.

Trying to make some brittle, Do-What-I-Mean solution for trying to auto-
magically select between Python versions is pursuing a path of endless
problems. Any solution that doesn't fix the actual problem, namely that
the scripts are buggy, is at best just a work-around and at worst is no
solution at all.


--
Steven
 
Reply With Quote
 
David Robinow
Guest
Posts: n/a
 
      07-26-2010
On Sun, Jul 25, 2010 at 8:40 PM, Edward Diener
<(E-Mail Removed)> 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?
 
Reply With Quote
 
Edward Diener
Guest
Posts: n/a
 
      07-26-2010
On 7/25/2010 8:41 PM, Steven D'Aprano wrote:
> On Sun, 25 Jul 2010 15:19:53 -0400, Edward Diener wrote:
>
>> On 7/25/2010 10:03 AM, Thomas Jollans wrote:
>>> On 07/25/2010 02:46 PM, Edward Diener wrote:
>>>> The problem with this is that you forget that a script can invoke
>>>> Python internally. So whether one uses the console or file association
>>>> method of invoking Python externally, any already written script can
>>>> use either internally.
>>>
>>> Maybe it's just me, but I think that a script that does this is quite
>>> simply badly written: it *will* break on systems that have multiple
>>> Python versions.

>>
>> Whether it is badly written or not in your opinion it is legal and
>> happens all the time.

>
> Yes, people write poorly written, buggy scripts all the time. Just
> because code is legal syntax doesn't mean it does what is intended, or
> that what is intended is sensible.
>
> If you have multiple versions of Python installed, and you call "python
> somescript.py" without knowing *which* Python will be called, it is
> neither sensible nor does it do what you intend. End of story.


Somebody is supplying you with a Python script and internally invoking
Python again. But that somebody does not have to be myself.

I am neither buying "End of story" nor that invoking Python internally
is an error. But if you believe it to be then you can root out all such
Python code, or correct it as you like. Even with co-existing versions
of Python installed I have better things to do with my time and
therefore will pursue a solution that will work for me in the face of
such code.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Loading multiple versions of the same package at the same time della Python 6 11-28-2008 11:08 AM
Tomcat/Apache coexisting Ike Java 4 10-04-2006 12:48 PM
"Cannot find assembly" problem with .NET 1.1 and 2.0 coexisting Nils Magnus Englund ASP .Net 3 09-07-2006 03:05 PM
Running multiple versions of Python on the same host.. Cowmix Python 3 07-10-2006 06:04 PM
Multiple versions of Python / PythonWin on the same machine? dananrg@yahoo.com Python 2 02-24-2006 11:17 PM



Advertisments