Mark Hammond wrote: > Yes, and each of these versions has broken various programs. Of all > people, Im surprised to see you falling for the MS hype, Jim. My experience is that it often works. I have also (who hasn't?) had the experience that mysterious bugs disappear by installing the newest DLLs. > > What this means is that if the new Python 2.0 (1.6?) simply names > > its DLL python15.dll just as before, everything Just Works almost. > > That is, it Just Works provided that foo.pyd only calls Python > > C functions whose interface has not changed. > > IMO, this constrains us too much. We can't afford this - we simply dont > have the resources. I guess I haven't made myself clear. I am not proposing that we freeze the C interface. I am not proposing that we scrutinize any *.pyd's for incompatabilities. I am proposing that we leave the "python15.dll" name the same. I am proposing that the various *.pyd authors themselves either provide newer versions, or declare that their *.pyd needs no newer version of python15.dll. It is a matter of odds. If we necessarily rename python15.dll for each version release, Python has a 100% chance of failing with an obscure error or crashing if it uses any *.pyd at all unless all *.pyd are replaced with new versions. If we do not rename python15.dll, then a *.pyd may or may not fail. My guess (only a guess) is that many will work OK. > > You can support Python 1.5 and 1.6 by removing the python*.dll > > from the Windows directories, and putting it in the directory > > of python.exe so it goes with the proper executable. > > We have discussed this over and over and over, ad nauseum. If you believe > the earlier discussions were bunk, please refute them. Otherwise, simply > re-asserting something that we have previously proven to be incorrect > doesnt help anyone. Putting python15.dll in with python.exe works fine for just using the interpreter python.exe, and it works fine for Python extensions. It fails when the client for python15.dll is not python.exe, but is some other client such as COM. That is, it fails to support Python embedding in general. I proposed that someone who needed multiple Python versions could use this solution provided that he/she had no use for embedding. Not as a general policy. > > Yes, and this is a major problem, and is un-Windows-like. > > :-) "Major Crashes" are un-Windows like? What is happening to this > group - It amusing that this statement could be made without the Linux > geeks making smart-arsed comments :-) Looks like Billy Boy really _is_ > taking over the world :-) I am a Linux geek myself. And Windows is more and more stable all the time. And yes, Bill is taking over the world and I doubt DoJ can stop him. JimA
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