On AIX, building a shared library for use by extension modules and which uses the Python 'C' API is way harder than it should be**; the best workaround we could find involves hijacking _PyImport_LoadDynamicModule to load the shared library and patch up the symbol references.
_PyImportLoadDynamicModule is undocumented, AFAICT. Am I not supposed to touch it? Is it likely to disappear or change its signature?
That's anybody's guess. I have no plans in this area, but it's only an external symbol because we wanted a logical separation between importdl.c and import.c. If someone has a great idea for refactoring this that involves changing its signature, I don't see why not. Now, maybe you're right that this *should* be documented and guaranteed API -- we've promoted internal APIs to that status before without removing the leading underscore (e.g. _PyString_Resize).
On a related note, I wonder about all of the _[A-Z] names in Python. I know that at least in C++, these names are reserved to the compiler implementation. I assume the same holds for 'C', and wonder if Python's use of these names is intentional, on the "to be changed someday" list, or something else.
They're reserved by standard C too, but I figure we'd be safe by using _Py as the prefix. Same thing really as assuming ASCII or 8-bit bytes -- standard C doesn't guarantee those either. --Guido van Rossum (home page: http://www.python.org/~guido/)