On Thu, 4 May 2006 13:19:46 -0400, "Tim Peters" <[EMAIL PROTECTED]> 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.) >> 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 ;-) 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 -- http://mail.python.org/mailman/listinfo/python-list
