[Python-Dev] _PyImport_LoadDynamicModule questions

[Guido van Rossum]

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

You're talking to the wrong guy.  I have no access to AIX, no
experience with it, and no understanding of it.  Somebody else will
have to judge your recommendation, not me.

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

Maybe Anthony Baxter can corrobborate your story.

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

They are for names that have to be external symbols because they are
used across multiple files, but are not part of the official API that
we recommend to extension writers.  We reserve the right to remove
these APIs or change them incompatibly (although when we find that one
of them has accidentally become useful in some way we usually don't do
that).

--Guido van Rossum (home page: http://www.python.org/~guido/)