Multiple Version Install?
David C. Ullrich
variables, whatever) if a person tried to install
versions 1.x and 2.x simultaneously on one Windows
system? Windows 98, if it matters.
(I can handle the file associations with no problem.)
Thanks.
**************************
If anyone feels like pointing out that there's simply
no reason to want to keep 1.x after installing the
current version: By all means talk me into that!
The problem is not that I'm concerned about backwards
compatibility of Python code. The problem is that I
use Python embedded in various Delphi programs,
including a "DIDE" that I use really a lot, via
a certain set of Delphi "components". These components
don't seem to work with 2.x. Presumably the PyDelphi
people have new versions of the components that do
work with Python 2.x. These presumably use much
newer versions of Delphi than what I have. A new
version of Delphi is not free... If I could use
Python 2.x when I need to while continuing to
use 1.x the way I have been for things that
don't need 2.x that would be convenient.
************************
David C. Ullrich
Fredrik Lundh
> Would there be issues (registry settings, environment
> variables, whatever) if a person tried to install
> versions 1.x and 2.x simultaneously on one Windows
> system? Windows 98, if it matters.
>
> (I can handle the file associations with no problem.)
in general, no.
(I usually have about a dozen Python's, or more, on most of my
windows boxes)
however, applications that look in the registry may only find the
last one you've installed.
</F>
David C. Ullrich
<fre...@pythonware.com> wrote:
>David C.Ullrich wrote:
>
>> Would there be issues (registry settings, environment
>> variables, whatever) if a person tried to install
>> versions 1.x and 2.x simultaneously on one Windows
>> system? Windows 98, if it matters.
>>
>> (I can handle the file associations with no problem.)
>
>in general, no.
Excellent. Thanks.
>(I usually have about a dozen Python's, or more, on most of my
>windows boxes)
>
>however, applications that look in the registry may only find the
>last one you've installed.
>
></F>
>
>
************************
David C. Ullrich
Tim Peters
> Would there be issues (registry settings, environment
> variables, whatever) if a person tried to install
> versions 1.x and 2.x simultaneously on one Windows
> system? Windows 98, if it matters.
>
> (I can handle the file associations with no problem.)
There are generally no issues beyond file associations. On Windows,
Python versions i.j.k and i'.j'.k' coexist happily so long as i != i'
or j != j'. For example, I currently have the python.org-released
Pythons 2.2.3, 2.3.5, and 2.4.3 installed on my Windows box. It would
be a challenge only if I wanted, say, 2.4.2 and 2.4.3 installed
simultaneously.
Another possible issue is that whenever the major or minor version
numbers (i or j) change on Windows, you also need to install matching
versions of any 3rd party extensions you want. The major and minor
version numbers appear in the _name_ of the core Python DLL (like
python23.dll and python24.dll), and extensions with C code must be
compiled to link with the correct version of the Python DLL.
> If anyone feels like pointing out that there's simply
> no reason to want to keep 1.x after installing the
> current version: By all means talk me into that!
If you've been using extensions with 1.j.k, then as above they have no
chance of working with 2.j'.k' bejore you install 2.j' versions of
those extensions. That's a good reason to keep an old version.
There have been thousands of bugfixes and language enhancements since
1.j.k too, and not all are 100% backward-compatible.
In all, best advice is to keep the old version around until you're
sure you no longer need it.
> The problem is not that I'm concerned about backwards
> compatibility of Python code. The problem is that I
> use Python embedded in various Delphi programs,
> including a "DIDE" that I use really a lot, via
> a certain set of Delphi "components". These components
> don't seem to work with 2.x. Presumably the PyDelphi
> people have new versions of the components that do
> work with Python 2.x. These presumably use much
> newer versions of Delphi than what I have. A new
> version of Delphi is not free... If I could use
> Python 2.x when I need to while continuing to
> use 1.x the way I have been for things that
> don't need 2.x that would be convenient.
That should work fine. I don't know about PyDelphi, but found what
appears to be a still-active discussion list:
http://groups.yahoo.com/group/pythonfordelphi/
The theoretical joy of open source is that if they _don't_ support the
Python+Delphi combo you have, you can fix that yourself ;-)
David C. Ullrich
wrote:
>[David C.Ullrich]
>> Would there be issues (registry settings, environment
>> variables, whatever) if a person tried to install
>> versions 1.x and 2.x simultaneously on one Windows
>> system? Windows 98, if it matters.
>>
>> (I can handle the file associations with no problem.)
>
>There are generally no issues
One more thing you Python guys got right.
Just curious: How does pythonxx.dll determine things
like where to find the standard library? That's the
sort of thing I'd feared might cause confusion...
>beyond file associations.
Which is no problem. Either you add "Run 1.x" and "Run 2.x"
to the context menu or you associate .py with a tiny
windowless .exe that emulates the UNIX thing, reading
the first line of the file and then running the
appropriate python.exe.
(Before I tried it I thought that second might slow
down startup, but evidently even Windows is willing
to load a program quickly if it's small enough - I've
never noticed any delay.)
> On Windows,
>Python versions i.j.k and i'.j'.k' coexist happily so long as i != i'
>or j != j'. For example, I currently have the python.org-released
>Pythons 2.2.3, 2.3.5, and 2.4.3 installed on my Windows box.
I wouldn't have bothered explaining why I cared except that
I was under the impression that the official line was that
if I wanted to use two versions I must be doing something
wrong. I guess not, fine.
> It would
>be a challenge only if I wanted, say, 2.4.2 and 2.4.3 installed
>simultaneously.
>
>Another possible issue is that whenever the major or minor version
>numbers (i or j) change on Windows, you also need to install matching
>versions of any 3rd party extensions you want. The major and minor
>version numbers appear in the _name_ of the core Python DLL (like
>python23.dll and python24.dll), and extensions with C code must be
>compiled to link with the correct version of the Python DLL.
No problem with the one emedding I want to use - no recompile
needed, it requires that I simply set the name of the dll as
a "property" of the "engine".
(But simply setting dllname = "python2whatever.dll" gives
errors about functions not found. Is this just me doing
something wrong or did functions with certain names
actually disappear? Not a complaint, just curious.)
Crossed my mind, but only briefly - "theoretically" seems right.
(One of the big improvements in later versions of Delphi is
reference-counted/garbage-colleted dynamically sized arrays.
Taking code using them and converting it to code with manual
memory management seems like it would be a fairly major pain.
Especially if a person wanted to get it right...)
But thanks, theoretically.
************************
David C. Ullrich
David C. Ullrich
<ull...@math.okstate.edu> wrote:
[...]
>Just curious: How does pythonxx.dll determine things
>like where to find the standard library? That's the
>sort of thing I'd feared might cause confusion...
Ok, it was a stupid question, cuz right there in the
registry it says
Python/PythonCore/1.5/PYTHONPATH = whatever.
All I can say is the last few times I wondered about this
question I did search the registry for PYTHONPATH and
didn't find it. Maybe I spelled it wrong or somthing.
************************
David C. Ullrich