OTOH, we could take chance to reorganize these macros from bottom up: when I started coding extensions I found them not very useful mostly because I didn't have control over them meaning "export this symbol" or "import the symbol". Especially the DL_IMPORT macro is strange because it seems to handle both import *and* export depending on whether Python is compiled or not.

This would be very nice. The DL_IMPORT/DL_EXPORT stuff is really weird unless you're working with it all the time. We were trying to build a plugin DLL for PythonWin and first you spend hours finding out that you have to set DL_IMPORT (and how to set it), and the you spend another few hours before you realize that you can't simply copy the DL_IMPORT and DL_EXPORT from, say, timemodule.c because timemodule.c is going to be in the Python core (and hence can use DL_IMPORT for its init() routine declaration) while your module is going to be a plugin so it can't. I would opt for a scheme where the define shows where the symbols is expected to live (DL_CORE and DL_THISMODULE would be needed at least, but probably one or two more for .h files). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm