Home Original page

some uglyness in Python imho

Jay Krell jay.krell at cornell.edu
Sat Sep 9 07:58:25 EDT 2000 
I'm just working on building Python 1.6 (and then 2.0, already did 1.5.2)
using a different build system (the Windows NT DDK's build.exe, like
recursive make, but very well factored so that mostly you only list what
sources you want to compile).

The following come to mind upon brief inspection of the code, based on
errors building:

*Python.dll should strive for a binary compatible interface across its
various configuration options.

It annoying for #ifdefs to propagate deep into code such that if you change
them you have to recompile everything instead of just one file. Like
#ifdef Py_TRACE_REFS
#define Py_InitModule4 Py_InitModule4TraceRefs
#endif

I'm not very familiar, but if possible, the .dll should export both and
which is used is either a command line option or depends on how a particular
module was built.

*#define staticforward extern

You can resolve this in a less compiler dependent, ugly way. Forward declare
the static functions in the file they are implemented in. Then
declare/initialize the static struct with the function pointers. Then define
the static functions.

*DL_IMPORT __declspec(dllexport,import,etc)

Is this strictly for Windows, or do Unix, Mac, etc. need them? (I'm pretty
sure Unix does not and Mac makes do at least with #pragmas at the top and
bottom of the header).
If they are only for Windows, you shouldn't use them. You can just use a
.def file without spoiling your source code.

*extern DL_IMPORT(PyTypeObject) PyCObject_Type;

Related, you should not, imho, export data, only functions. There are a few
problems with exporting data.
1) A .def file is no longer sufficient.
2) You can't "delayload" anything with data exports, with VC6's -delayload
switch.

Yes, msvcrt.dll and mfc42.dll export data. I don't think they should.
Exporting data is more efficient, but I doubt it's worth it. All these
DLL_IMPORT/EXPORT gyrations, in so many source bases.. You can replace
exported data just with a function that returns the address. Or, better yet,
a function to get, and a function to set. That way you have a hope of thread
safety. If you do the first, you can provide a macro to hide the deref

< DL_IMPORT(int) i;
> int* GetIPointer(void);
> #define i (*GetIPointer())

 - Jay
More information about the Python-list mailing list