> > The problem this will lead to is that Python 1.6.0 and 1.6.1 will > > not be able to be installed concurrently. > > Same thing happened with Python 1.5, so we're no worse off. If we do want > this behavior, then we need to add another version digit... Actually, I don't plan on releasing a 1.6.1. The next one will be 1.7. Of course, alpha and beta versions for 1.6 won't be able to live along, but I can live with that. > > Putting entries on the > > PATH doesnt solve the underlying problem - you will only be able to > > have one Python 1.6 directory on your path, else you end up with the > > same coflicts for the DLL. > > > > I dont see any better answer than System32 :-( Thoughts? > > I don't have a better answer, as you and I explained on several occasions. > Dunno why Guido decided to skip our recommendations, but hey... it > happens :-). Actually, I just wanted to get the discussion started. It worked. :-) I'm waiting for Tim Peters' response in this thread -- if I recall he was the one who said that python1x.dll should not go into the system directory. Note that I've made it easy to switch: the WISE script defines a separate variable DLLDEST which is currently set to MAINDIR, but which I could easily change to SYS32 to get the semantics you prefer. Hey, we could even give the user a choice here! <0.4 wink> > IMO, put the DLL back into System32. If somebody can *demonstrate* (not > hypothesize) a mechanism that works, then it can be switched. > > The underlying issue is this: Python16.dll in the app directory works for > Python as an executable. However, it completely disables any possibility > for *embedding* Python. On Windows, embedding is practically required > because of the COM stuff (sure... a person could avoid COM but...). Yes, I know this. I'm just not happy with it, and I've definitely heard people complain that it is evil to install directories in the system directory. Seems there are different schools of thought... Another issue: MSVCRT.DLL and its friend MSVCIRT.DLL will also go into the system directory. I will now be distributing with the VC++ 6.0 servicepack 1 versions of these files. Won't this be a problem for installations that already have an older version? (Now that I think of it, this is another reason why I decided that at least the alpha release should install everything in MAINDIR -- to limit the damage. Any informed opinions?) David Ascher: if you're listening, could you forward this to someone at ActiveState who might understand the issues here? They should have the same problems with ActivePerl, right? Or don't they have COM support? (Personally, I think that it wouldn't be so bad if we made it so that if you install just Python, the DLLs go into MAINDIR -- if you install the COM support, it can move/copy them to the system directory. But you may find this inelegant...) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4