My selfish desire is better support for programs that use the "C API" from some other language/runtime via an FFI (foreign function interface). In my case it's

My selfish desire is better support for programs that use the "C API" from some other language/runtime via an FFI (foreign function interface). In my case it's .NET and P/Invoke, where I'm facing challenges similar to those faced by Python.NET, but the same things apply to other FFIs, (although they are ameliorated if you assume a common, system-wide C compiler as is usually the case with linux, which is probably why this case seems rarely to be considered). Macros are zero use in these situations. There should be exported functions corresponding to these. This PEP sounds like a move in the right direction, but I don't see it mentioned that these macro-replacing inline functions will also be exported from the library so they're accessible with GetProcAddress (windows) or dlsym (linux). If they will be, it will make me very happy. There's an asssumption in cpython "C API" development that clients are only written in C/C++. Even the Stable ABI and its improvements (which have been a great boon) are only discussed in terms of the ABI not changing, never in terms of actually defining an ABI. It would be great to have an interface you could interact with via an FFI without having to make assumptions about how it was compiled, even if it involves stuff like calling a bunch of functions to discover how big a ssize_t is, etc.