[Python-Dev] _PyImport_LoadDynamicModule questions

[David Abrahams]

From: "Guido van Rossum" <guido@python.org>

> > _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).

Actually, I'm not going to try to convince anyone to make this a stable
public API until after I've failed to convince you that maybe there ought
to be a libpython.so on AIX. On AIX, the dynamic linking model is in some
ways a lot like that of Windows, and it's really tough for a shared library
to get ahold of symbols from an executable (witness the strange
implementation of the title function of this email on AIX). If it didn't
break something else, it might be a major simplification to move the bulk
of Python into a shared library on this platform, just as it is on
Windows... especially for poor unsuspecting souls (like me) who try to use
the Python 'C' API from a shared library (not an extension module). Without
some major hackery to patch up those symbols, it unceremoniously dumps core
when you try to call Python functions.

> > 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.

OK; what's the intended meaning of the prefix?

-Dave