Unfortunately, this won't make it into 3.3. -- The self-review of mpdecimal.c had priority and was extremely time consuming.

See issue #7652 for context.

I've looked at this, and the question is: Do we really need a capsule
API?  All relevant symbols in _decimal start with Py* and shouldn't
need to be static.

On 17.10.2013 21:01, Stefan Krah wrote:
> 
> Stefan Krah added the comment:
> 
> I've looked at this, and the question is: Do we really need a capsule
> API?  All relevant symbols in _decimal start with Py* and shouldn't
> need to be static.

You need a capsule in order to use the C API from other extension
modules. See the datetime module for an example.

I believe you, but I'd like to understand why. :)

It seems to me that a module and also PyInit_xxx() can be loaded portably.
Say the handles to the module are cached somewhere after loading and
initializing.  I think this already happens in Python/dynload_shlib.c.

Why can't another module use a slightly modified form of _PyImport_GetDynLoadFunc()
to get any non-static function apart from PyInit_xxx() by re-using the cached
handle?

On 18.10.2013 11:39, Stefan Krah wrote:
> 
> Stefan Krah added the comment:
> 
> I believe you, but I'd like to understand why. :)

:-)

> It seems to me that a module and also PyInit_xxx() can be loaded portably.
> Say the handles to the module are cached somewhere after loading and
> initializing.  I think this already happens in Python/dynload_shlib.c.
> 
> Why can't another module use a slightly modified form of _PyImport_GetDynLoadFunc()
> to get any non-static function apart from PyInit_xxx() by re-using the cached
> handle?

This may work on Linux (and probably does if you use the right
DL flags), but I don't think this works reliably or at all on other
platforms such as Windows. Symbols from shared libs are not necessarily
available to all other shared libraries in the same process.

CObjects, which Capsules originate from, were added to address this
problem in a portable way. It's the Python standard approach to
"importing" C APIs from other extension modules.

Marc-Andre Lemburg <report@bugs.python.org> wrote:
> This may work on Linux (and probably does if you use the right
> DL flags), but I don't think this works reliably or at all on other
> platforms such as Windows. Symbols from shared libs are not necessarily
> available to all other shared libraries in the same process.

Thanks. On Linux the scheme works (I stored the DLL handle in
the PyModuleObject and added a function PyModule_GetSymbol()).

Is this superseded by issue 22194 now or the other way round?

I think #22194 is a duplicate issue.