> That's what I meant. The issue here is that Python's libmpdec is not exposed
> to third-party code at all. Also there should probably be a (thin?) API to get
> at the underlying mpdec object from a cdecimal PyObject (apologies for the poor
> wording, I'm actually not acquainted with the libmpdec APIs).


People were asking for libmpdec symbols to be hidden (#16745). It's easy to
revert, just a couple of pragmas in the headers.



> As for the Capsule method, well, at least it would be better than nothing
> (or than any platform-specific hack).

Platform specific maybe, but no hack:  I was thinking about storing the DSO
handle in the PyModuleObject struct and add functions to lookup symbols.  
I'm attaching a diff for Linux -- It has been a while, but I'm rather certain 
that the corresponding scheme also worked on Windows (can't test now, my 
Windows VM is defunct).

That would leave the usual troublemakers AIX etc., which have sketchy support
anyway.

Of course getting all symbols for a module should be done in one separate
file (_decimal_api.c), the diff is just a demonstration.



> Relatedly, is the libmpdec ABI stable?

Yes, starting from 2.4.0.


> That is, if I build a separate libmpdec, can I expect it to handle cdecimal's
> innards fine, or will there be problems?

You need to initialize libmpdec in the exact same way as in _decimal.c.
Generally it should be fine (though I'm not thrilled by the idea :), but
I suspect there could be locale problems on Windows with a second libmpdec.