[Python-Dev] Embedding Python when using different calling conventions.

[Jack Jansen]

> 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