DLL in the system directory on Windows
However, as we import data from Python16.dll rather then purely addresses, we can't use any of these interception solutions.
What's wrong with: #define PyClass_Type *(GetProcAddress(hdll, "PyClass_Type")) I have only looked at PythonCOM15.dll, and it seems that there are only references to a handfull of exported data items: some Py*_Type, plus _PyNone_Struct, _PyTrue_Struct, _PyZero_Struct. Thomas Heller
However, as we import data from Python16.dll rather then purely addresses, we can't use any of these interception solutions.
What's wrong with:
#define PyClass_Type *(GetProcAddress(hdll, "PyClass_Type"))
My only objection is that this is a PITA. It becomes a maintenance nightmare for Guido as the code gets significantly larger and uglier.
I have only looked at PythonCOM15.dll, and it seems that there are only references to a handfull of exported data items:
some Py*_Type, plus _PyNone_Struct, _PyTrue_Struct, _PyZero_Struct.
Yep - these structs, all the error objects and all the type objects. However, to do this properly, we must do _every_ exported data item, not just ones that satisfy COM (otherwise the next poor soul will have the exact same issue, and require patches to the core before they can work...) Im really not convinced it is worth it to save one, well-named DLL in the system directory. Mark.
[I wrote]
My only objection is that this is a PITA. It becomes a ... However, to do this properly, we must do _every_ exported ... Im really not convinced it is worth it to save one, well-named DLL in the system directory.
ie, lots of good reasons _not_ to do this. However, it is worth pointing out that there is one good - possibly compelling - reason to consider this. Not only would we drop the dependency from the system directory, we could also drop the dependency to the Python version. That is, any C extension compiled for 1.6 would be able to automatically and without recompilation work with Python 1.7, so long as we kept all the same public names. It is too late for Python 1.5, but it would be a nice feature if an upgrade to Python 1.7 did not require waiting for every extension author to catch up. OTOH, if Python 1.7 is really the final in the 1.x family, is it worth it for a single version? Just-musing-ly, Mark.
However, as we import data from Python16.dll rather then purely addresses, we can't use any of these interception solutions.
What's wrong with:
#define PyClass_Type *(GetProcAddress(hdll, "PyClass_Type"))
My only objection is that this is a PITA. It becomes a maintenance nightmare for Guido as the code gets significantly larger and uglier. Why is it a nightmare for Guido? It can be done by the extension writer: You in the case for PythonCOM.dll.
I have only looked at PythonCOM15.dll, and it seems that there are only references to a handfull of exported data items:
some Py*_Type, plus _PyNone_Struct, _PyTrue_Struct, _PyZero_Struct.
Yep - these structs, all the error objects and all the type objects.
However, to do this properly, we must do _every_ exported data item, not just ones that satisfy COM (otherwise the next poor soul will have the exact same issue, and require patches to the core before they can work...) IMHO it is not a problem of exporting, but a question how *you* import these.
Im really not convinced it is worth it to save one, well-named DLL in the system directory. As long as no one else installs a modified version there (which *should* have a different name, but...)
Mark.
Thomas Heller
participants (2)
-
Mark Hammond -
Thomas Heller