> > This is where we are now. I agree that we should not crash, > > but it seems to me you havent solved anything - individual > > .pyd authors needing to tell users about each individual > > .pyd isnt a solution. > At least if Python can detect that a .PYD is out of date you know > to ask for a newer .PYD or build it yourself. A crash is bad PR for > the .PYD and Python. We all agree on this - hence this discussion. My point was that I'm not clear how the proposal moved us closer to this goal. > > > True. And on Windows, there is a standard Version resource > > > string which gives the DLL version, and can be read without > > > loading the DLL. This string is referenced by the Wise (and > > > other) installers to decide whether a DLL is newer and should > > > be replaced. > > > > Im not sure how this helps us. Do you mean that "initfoo" > > should use the Windows resource/version APIs to determine > > if it can load? > As I pointed out you cannot use Py calls from a .PYD to find out > the version as the .PYD calls the function in the old PYTHON15.DLL > not the new one. Firstly, this doesn't answer my question, so I'm not sure why you needed to restate this assertion. I can only assume that the answer to my question, in your opinion, is "yes"? Secondly, I'm not sure why this is a problem. Sure, we can't use the version number, but the extension could, for example, call Py_IsInitialized() - this is likely to be a good indication if our linked DLL is the "correct" one for this process. The problem is not intractable - someone who cares enough should put together a patch, test it, and submit it. Talk-is-cheap-ly, Mark.
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